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.