Planning for OAuth 2.0

oauth-sunriseHaving said that*

With more than 2 years hands-on experience, we are ready to begin work on the next major version of the OAuth protocol. When I brought OAuth to the IETF, the plan was to simply clean up the specification, make small security and interoperability changes, and ship something very similar to OAuth Core 1.0. The IETF OAuth Working Group charter even went as far as suggesting that the work will produce a minor 1.1 revision of the specification. Nothing to write home about.
Somewhere along the way I changed my view on what is the most effective use of the working group time. The web development landscape is changing rapidly (is PHP4 still a critical use-case?) and with it, developers get better access to the lower layers of the network stack.

In addition, there is a fundamental difference between a grassroots community working on a specification optimized for quick and easy adoption, and a mature standards setting organization setting long term goals and applying its influence to increase adoption. The first was critical to make the second possible, but now that we have accomplished that, time to change strategy.

The following is my wish-list for OAuth 2.0:

Separate between authentication and authorization

This has been a sore point from the beginning with people arguing whether OAuth is an authentication protocol or an authorization protocol, with the word ‘delegation’ being used as a compromise. The truth is, OAuth contains both.

The redirection-based flow is authorization (with user authentication left intentionally out of scope), and the signature flow is authentication. By separating the two, OAuth becomes more modular and easier to understand.

Simplify authentication

The signature base string is the most problematic part of the current specification. It was designed based on the assumption that clients and servers lack access to many parts of the raw HTTP request. This is no longer the case which allows significant amount of simplification. And even where it is, we should strive to improve this situation by using the new effort to push for changes.

There are also use-cases in which a bearer token approach is sufficient without the need for additional cryptography (similar to how many cookie-based authentication work).

In addition, the use of RSA for accessing individual resources has proved to be an unpopular feature of the protocol, as well as the need to include client credentials when making protected resources requests.

Support more token issuance options

OAuth currently includes a single redirection-based method of obtaining tokens. This method is highly optimized for web-based applications running inside a desktop-size browser. Trying to deploy OAuth for mobile devices or installed applications is complex and generally unusable. This is an area where WRAP can be extremely useful and many of its flows can be adopted to work with OAuth authentication.

What’s next?

Now that OAuth 1.0 enjoys a newly rewritten specification which incorporates many of the known problems in both the specification and the protocol, it can be used as the basis for 2.0. It also gives 1.0 a bit more breathing room and makes it a viable option for use-cases we decide to drop in the 2.0 version.

Over the next few weeks I plan to invest most of my time editing the working group drafts based on these ideas and present a new draft for the working group to consider. Stay tuned.

2 thoughts on “Planning for OAuth 2.0

  1. Hey Eran,

    I have a few web applications running which delegate access to a remote, oauth protected resource directly to the browser using a http redirect where the redirect location is a signed url with the oauth parameters in the query string.

    As I understand your post, this probably won’t be supported in OAuth 2.0 anymore.
    Is that true? Have you thought about use-cases like mine?
    Will there be any other way to accomplish something like this?


    • This use case was mentioned on the list and is still being discussed. I think we are likely to include some mechanism to allow sending the authorization header encoded in the URI query. What this means is that you will take all the individual OAuth parameter, pack them, and include them as a single parameter in the query. This will give you the functionality you want but without having to parse the entire query, normalize its parameters, etc. Just remove the special OAuth parameter from the very end. But again, this is just an idea and it is still being discussed.

Comments are closed.