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?

(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.