The Case for OAuth 3.0: Why Now?

When I proposed that we move toward OAuth 3.0, one question kept coming back to me: Why now? OAuth 2.0 is incredibly successful, why would we do anything to imply that we need something else?

From my view, the answer comes down to a combination of a the rising of a need for something different and, at the same time, the opportunity for a comprehensive solution to fill that need.

The Need

As we’ve already covered, OAuth 2.0 is coming up short in some of the ways that people are wanting to use it. We’re seeing a number of different extensions for intent registration, key binding, user interaction modes, and other extended functionality that OAuth 2 was never meant to tackle.

Make no mistake, this extensibility is one of OAuth 2’s strengths, and perhaps even key to its widespread success. Even so, OAuth’s extensions are getting to a confusing point for developers. Are you supposed to use token exchange, or the assertion flow? And is that a client assertion or an assertion token? And if you’re identifying a resource server, is that the audience, the location, the resource, or just another scope value? All of these are valid interpretations of solving that need, and they conflict with each other to the point that any system that shows up today has to define a way that they fit together.

And then there’s the problem with decisions baked into OAuth 2’s core that are affecting us to this day. Simple things like the use of form-encoding for request values (instead of JSON) make things like Rich Authorization Requests difficult to build and lead to the kinds of awkward double-encoding that shows up in that draft. More complex decisions like beginning all interactive flows with a web redirect limit the kinds of use cases that OAuth 2 can be applied to without significant diversion from its goals.

Corollary to this is the set of things that OAuth 2 just doesn’t have a good model for, like ephemeral clients with their own keys, or clients that want to send and receive user information directly, or interaction modes that don’t involve a web browser. The community has tried to address needs like these with new extension grant types, but shoehorning such different functionality into the OAuth 2 framework is awkward at best and potentially dangerous at worst, when used improperly.

The Opportunity

Most of the problems with OAuth 2 aren’t new, nor are they surprises to people who use it regularly. What’s different about right now is that I believe we have the opportunity to do something about it beyond just back-patching things into the existing OAuth 2 framework.

The technology of the web has grown leaps and bounds since OAuth 2.0 was first ratified as an RFC in 2012. Our entire notion of what constitutes a client or server application has changed drastically in that time, and the way these things are built today is radically different.

In addition, there are some exciting new technologies that just didn’t exist back then. Technologies like CORS and COSE open new possibilities for different kinds of apps in a world that OAuth 2 never counted on. Complex ecosystems like distributed ledgers and mobile application platforms offer unique means of communication, identification, and verification that the pure-web world of OAuth 2 isn’t made for. HTTP message signing and MTLS deployments built with terminating proxies in mind give us security properties to build on that we couldn’t depend on before.

On top of that we have a decade of experience with OAuth 2 deployments to build on, and more than that if you count OAuth 1 and its predecessors. Not only do we now realize the extent of the problems that the implicit flow can cause, we also have better underlying tools that we don’t need to use it even for the use cases it was targeted at.

With this combination of progress and experience, I believe that right now, we have a good chance to start building the next generation authorization delegation protocol. This isn’t just about fixing a few annoying things in OAuth 2, this is about building something more capable, more flexible, more usable, and more secure than OAuth 2 can be, all while being a better fit for today’s (and tomorrow’s) technology stacks. Instead of building on the hacks and workarounds of the past, we can now build something that’s fit better to the direction of the future.

The time has come to start building. This is work that will take quite some time to complete, on the order of years. And even when it’s done, I fully expect many to have a long transition away from OAuth 2 for cases where OAuth 2 still works. Many years from now, someone will probably have a better idea to replace it, because that’s how technological progress happens.

But right now, we need to start building something that works before developers of the world build the next decade of internet security on a leaky pile of mismatched pieces. Join us on TXAuth in the IETF to help us build a better future.

Justin Richer is a security architect and freelance consultant living in the Boston area. To get in touch, contact his company:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store