Fixing OAuth 2.0 with OpenID Connect?

I didn’t like Nat’s Fixing OAuth? post.

“For protecting a resource with low value, current RFC6749 and RFC6750 with an appropriate constraint should be good enough…For protecting a resource whose value is higher than a certain level, e.g., the write access to the Financial API, then it would be more appropriate to use a modified protocol.”

I agree that write access to a financial API is a high value operation (and security measure will go far beyond authentication and token requests) – but most users and implementers of OAuth 2.0 based system would surely disagree that their resources only have a low value.

Then on the other hand I agree that OAuth 2.0 (or rather RFC6749 and 6750) on its own indeed has its issues and I would advise against using it (important part “on its own”).

Instead I would recommend using OpenID Connect – all of the OAuth 2.0 problems regarding client to provider communication are already fixed in OIDC – metadata, signed protocol responses, sender authentication, nonces etc.

When we designed identity server, we always saw OpenID Connect as a “super-set” of OAuth 2.0 and always recommended against using OAuth without the OIDC parts. Some people didn’t like that – but applying sound constraints definitely helped security.

I really don’t understand why this is not the official messaging? Maybe it’s political?

Screenshot 2016-07-29 08.42.17.png

(no response)

Wrt to the issues around bearer tokens – well – I really, really don’t understand why proof of possession and HTTP signing takes that long and seems to be such a low priority. We successfully implemented PoP tokens in IdentityServer and customers are using it. Of course there are issues – there will always be issues. But sitting on a half done spec for years will definitely not solve them.

So my verdict is – for interactive applications, don’t use OAuth 2.0 on its own. Just use OpenID Connect and identity tokens in addition to access tokens – you don’t need to be a financial API to have proper security.

 

This entry was posted in IdentityServer, OAuth, OpenID Connect, WebAPI. Bookmark the permalink.

14 Responses to Fixing OAuth 2.0 with OpenID Connect?

  1. alhardy says:

    When you say “don’t use OAuth 2.0 on its own”, would you also advise against the resource owner password grant type for first party native applications (mobile)?

    I understand this grant type isn’t part of OIDC, do you see any issues in supporting id tokens in this flow?

  2. alhardy says:

    That’s fair enough and I agree.

    What’s tough re OIDC on native is convincing UX and mobile devs that it’s not so bad having an almost once off redirect to web view for login (inc partial flows) when the majority of top rated apps have native logins :( Then the argument arises of “OIDC is only for third parties, we don’t need”, so let’s invent our own protocol on top of it :)

    • Resource owner has a place for 1st party apps – as long as you are aware what you are missing (like SSO, federation etc).

      • I don’t see a point in “inventing” id tokens for resource owner though.

      • alhardy says:

        I’ve watched your talk, it’s a very good overview thank you for that.

        We’re using idsrv and have a migration process as part of our partial auth flow (including other steps not related to migration), I don’t see the point in “re-inventing” this for native using resource owner and going down the path of supporting “partial tokens” in the same way we have “partial auth cookies”.

  3. We are using IdentityServer3 Framework to implement OAuth2. You mention that the important part is that we should ensure we use the OIDC parts for enhanced security.

    I am not sure as to how this is done. Is it by ensuring the clients use the IdentityModel.OidcClient instead of IdentityModel.Client? Is it possible to force Identity Server to only support OAuth2 using the OIDC parts?

  4. RO flow is not part of OIDC. so no.

    But RO flow does not have the same problems because no user interaction is involved. It has different shortcomings though (more feature wise).

  5. sakimura says:

    Sorry I missed your tweet.

    My advice obviously is to use OIDC if it is politically ok. There seems to be people who are not though.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s