What's going on with OAuth?

Over the past week there’s been a variety of incorrect information shared about what’s going on with the OAuth protocol. Chris Messina (Google), Dick Hardt (Microsoft), Eran Hammer-Lahav (Yahoo!), and I (Facebook) wrote this post to help provide a bit more clarity.

The OAuth protocol enables users to provide third-party access to their web resources without sharing their passwords; kind of like a valet key for the web. To date, OAuth 1.0a is the most successful such protocol deployed on the web. The origins of OAuth date back to late 2006, when a small group of web engineers, tired of reinventing the API authorization wheel, came together to find a common, open solution.

The protocol was derived from several existing API authorization protocols, including AOL, Flickr, Google, Microsoft, and Yahoo!. By developing a unified approach to API authorization, the goal was to reduce the burden of implementing any one of these protocols, and provide third party applications a more convenient and secure way to access user data. It is also well-established that security protocols are hard and often suffer from potential exploits. By focusing on an single, open protocol, the community could reduce the likelihood of an attack and respond faster when one occurs.

In the past two years, the number of services that require users to divulge their passwords to enable third-party access — the so-called password anti-pattern — has decreased dramatically. Today the most well-known and used deployment of OAuth 1.0a is the Twitter’s API. (If you’re interested in a more detailed explanation of OAuth, check out The Authoritative Guide to OAuth 1.0.)

Last year OAuth transitioned to the IETF as a new Working Group to produce version 1.1 which would be suitable for publication as an Internet Standard. The working group was tasked with reviewing the security and interoperability properties of the protocol, while maintaining as much backwards-compatibility as possible. As is sometimes the case in such efforts, there was little interest among the community in such a minor cleanup.

Introducing WRAP

At the same time, new use cases emerged as well as a significant amount of hands-on experience about the shortcomings and gaps in the 1.0a version of the protocol. A small group of developers herded by Dick Hardt started work on simplifying the protocol, inspired by the OAuth Session Extension proposed by Yahoo!. Originally dubbed “Simple OAuth”, it was later renamed to WRAP (Web Resource Authorization Protocol) to reflect the fact that it is a different protocol. It is now known as OAuth WRAP.

WRAP attempts to simplify the OAuth protocol, primarily by dropping the signatures, and replacing them with a requirement to acquire short lived tokens over SSL. It is not an even trade-off, and the new proposal has a different set of security characteristics, benefits, and shortcomings.

In 2007 when OAuth 1.0 was being created, SSL was used sparingly for APIs. As CPUs have become faster and more specialized SSL hardware has been deployed, it has become increasingly possible to operate APIs over SSL. Some APIs, like the Google Health Data API or Yahoo!’s Fire Eagle API, operate fully over SSL anyway as developers are interacting with non-public data. Using SSL obviates the primary purpose of the cryptography used in OAuth 1.0a, which was designed for transferring data over insecure channels.

WRAP addresses two areas in which the 1.0a protocol is lacking: it offers new ways to obtain tokens, and it evolves the architecture to enable other roles to issue tokens (other than the server). OAuth 1.0a offers a single browser-based redirection flow used to send the user from the application to the server, obtain approval, and return to the application. WRAP adds a few new flows for obtaining authorization and tokens mainly designed around providing better experiences on devices such as your XBox, desktop applications like TweetDeck, or fully JavaScript based implementations like Facebook Connect. And unlike 1.0a where the server issues and verifies every token, the tokens in OAuth WRAP are short lived and can represent claims issued by an authorization server, providing scale and security benefits for large operators.

Judging by the original “Simple OAuth” moniker, the goal behind WRAP was not to confuse developers or compete with OAuth. The intention, rather, was to promote OAuth and increase long term adoption by offering an SSL variant. Therefore, if you’re building a new API today and are trying to decide between deploying OAuth 1.0a or OAuth WRAP, nine times out of ten you should continue deploying OAuth 1.0a. But start experimenting with WRAP when its features are important to you and you are comfortable making changes as it evolves.

Building OAuth 2.0

WRAP brought the use cases and experiences that inspired it to the attention of the IETF working group. The consensus is that we now have enough implementation experience and new requirements to begin work on OAuth 2.0, instead of a minor revision. OAuth 2.0 will likely contain two parts, one defining an authentication scheme for accessing resources using tokens, and the second defining a rich set of authorization schemes for obtaining such tokens. By separating the two parts, we will be able to provide the right level of abstraction and modularity to support both the SSL-based approach taken by WRAP as well as the existing signature-based approach taken by 1.0a.

In many ways, OAuth 2.0 will be the result of combining the best ideas from both protocols. The authentication part will built on top of 1.0a while the authorization part will build on top of WRAP. It is important to remember that it is very early in the process, and that all these decision will be made by the members of the IETF OAuth working group. In other words, by those who show up. The goal is to have a set of stable drafts for OAuth 2.0 by the upcoming IETF OAuth Working Group meeting in March at the 77th IETF meeting.

For those implementing OAuth 1.0a today, a new edition has been published as an RFC draft which was accepted by the community as a replacement for the original 1.0a specification. This new specification does not change the protocol, but is more readable, includes many clarifications, errata, and examples, and thus easier to implement.

If you’re interested in keeping track of what’s going on with OAuth, Hueinverse’s OAuth page is a great place to watch. To get involved and take part in this important work, dig into the IETF OAuth Working Group and WRAP discussion list.

tags: , ,
  • Meng Weng Wong


  • Josh Fraser

    Great writeup! I know a lot of people have been struggling to get theirs heads around the differences between OAuth and WRAP. Thanks for the taking the time to write up a clear explanation.

  • Marc Hedlund

    Argh. So irritating.

    I’m glad to see WRAP coming about and I hope it will help make OAuth a lot better as a standard.

  • John Mitas

    So OAuth 2.0 is the BEST ideas from both protocols (WRAP-authorization & 1.0a-authentication)

    So building to WRAP exclusively doesn’t guarantee compliance with OAuth2.0 as some features may not make the cut?

  • Ron Biv

    They should call it oAuth WAIT instead of WRAP

  • Eran Hammer-Lahav

    @John Mitas: Implementing WRAP is pretty much guaranteed not to be compatible with OAuth 2.0. While the flows are likely to make it into the new work, the details on how parameters are sent and named, as well as many other details are most likely to change. However, the most important part of WRAP is how it addresses new use cases, especially new user interface scenarios. Experimenting with it today will help improve these solutions within 2.0.

  • Dave Peck

    WRAP is a nice experiment, but it shouldn’t be viewed as a standard to implement. I hope it has a positive influence on OAuth 2.0, and isn’t a distraction from completing that spec.

  • Dan Brickley

    Thanks for the comprehensive technical writeup – very useful to have this all in one place.

    I’ve been strongly encouraging developers and researchers to explore OAuth for a couple of years, and have always portrayed the OAuth scene as an informal, open collaboration which you could engage with by joining a mailing list. The sudden appearance of WRAP has done some damage to that picture, since it seems to have sprung fully-formed into existence.

    http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/16d3dc8ea4ec3680 …alludes to a former forum in which the WRAP design took place.

    If this isn’t public (I can’t find it… but happy to be wrong!), it would be interesting to know what the factors were which meant that this was done privately. Every time such a ‘suprise design’ is revealed, it reduces the confidence non-insiders have in the public forums and processes around collaboratively built standards. Folk who joined the OAuth lists last year thinking they were in the right place might be feeling pretty dumb now…?

    Nobody can complain if a group of collaborators decide to chat a bit offline before making a polished proposal. But it seems what happened with WRAP was closer to a full-fledged WG of hand-picked experts and stakeholders. For those of us who have been trying to make a case for W3C to operate more in public, it’s a shame not to be able to hold up OAuth any more as an example of where public collaborations work well…

    Will the earlier WRAP design discussions be put on the public record?

  • Michael R. Bernstein

    Dan, I think this is the group being referenced:

  • Kevin Turner

    Good to know. Can you post this to blog.oauth.net? This is a useful post and currently visitors to oauth.net won’t find it unless they happen to look at this month’s email archives.

  • Oauth Fan

    So OAuth 1 does NOT require ssl?
    I thought it did