The Case for OAuth 3.0

It’s been about a year since I proposed that we should move past OAuth 2.0, and a lot has happened since then to tackle some of the issues that I raised. I helped lead the TxAuth session at IETF 106 in Singapore last week, and we had a number of side meetings and follow ons from that to discuss the implications. So far, we’re seeing two major approaches: extending OAuth 2.0, and building a new protocol from the ground up. I think there’s room for both in the world, for different reasons.

Extending OAuth 2.0

OAuth 2 has been one of the most wildly successful security protocols on the internet to date, and it’s been extended in all kinds of interesting and specialized ways. For example, the Rich Authorization Request (RAR) draft specification details a way to move beyond the limits of the scope parameter, while the Pushed Authorization Request (PAR) draft specification provides a way to avoid a lot of the problems with the front channel. When combined through the JOSE-based request (JAR) and response (JARM) mechanisms backported from OpenID Connect, we’ve got a pretty rich and powerful intent registration pattern.

These extensions don’t always play nicely with each other, nor do they always play nicely with legacy applications. The PAR, CIBA, and Device Authorization Grant specs each define their own endpoint for doing essentially the same intent registration step, but in slightly different ways. And take PKCE for another example; it allows a native client to protect itself against code theft and injection attacks, but if the AS doesn’t support the PKCE extension, the request will still succeed but without any of the PKCE protections and with the client being none the wiser of its vulnerability. And those Rich Authorization Requests? They need to live in a world that already has OAuth 2.0 scopes, OpenID Connect claims, Proof of Posession aud (audience) , and the new resource indicator field deployed. The combinatorics of these alone are frightening, and any AS that wants to support all of these for different APIs certainly has its work cut out.

On top of that, we’ve got a whole series of Best Current Practice documents for OAuth 2 to deal with native apps, single-page apps, JWTs in general, JWTs as access tokens, and OAuth 2 as a whole. Developers today need to navigate all of these extensions and…