Introducing OAuth 2.0

Two weeks ago, the IETF OAuth Working Group published the first draft of the OAuth 2.0 protocol. OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords. OAuth 1.0 was published in December 2007 and quickly become the industry standard for web-based access delegation. A minor revision (OAuth 1.0 Revision A) was published in June 2008 to fix a security hole. In April 2010, OAuth 1.0 was published as RFC 5849.

OAuth 2.0 is a completely new protocol and is not backwards compatible with previous versions. However, it retains the overall architecture and approach established by the previous versions, and the same introduction (from the Official Guide to OAuth 1.0) still very much applies.

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.

As the web grows, more and more sites rely on distributed services and cloud computing: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services.

The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provide these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.

OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.).

For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service.  Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.

The new draft represents a yearlong discussion around goals and requirements for the protocol with participants from a wide range of companies including Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google. OAuth has long been the poster-child of rapid open technology adoption, and 2.0 is no exception – Facebook and Twitter already announced support even before the first draft was officially published.

Why a New Version?

OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s API Auth and Google’s AuthSub. The result represented the best solution based on actual implementation experience. With over 3 years of experience working with the protocol, the community learned enough to rethink and improve the protocol in three main areas where OAuth 1.0 proved limited or confusing:

Authentication and Signatures

The majority of failed OAuth 1.0 implementation attempts are caused by the complexity of the cryptographic requirements of the specification. The fact that the original specification was poorly written didn’t help, but even with the newly published RFC 5849, OAuth 1.0 is still not trivial to use on the client side. The convenient and ease offered by simply using passwords is sorely missing in OAuth.

For example, developers can quickly write Twitter scripts to do useful things by using their username and password. With the move to OAuth, these developers are now forced to find, install, and configure libraries in order to accomplish what was before possible with a single line of cURL script.

User Experience and Alternative Token Issuance Options

OAuth includes two main parts: obtaining a token by asking the user to grant access, and using tokens to access protected resources. The methods for obtaining an access token are called flows. OAuth 1.0 started out with 3 flows: web-based applications, desktop clients, and mobile or limited devices. However, as the specification evolved, the three flows were merged into one which (on paper) enabled all three client types. In practice, the flow works fine for web-based applications but provides an inferior experience elsewhere.

As more sites started using OAuth, especially Twitter, developers realized that the single flow offered by OAuth was very limited and often produced poor user experiences. On the other hand, Facebook Connect offered a richer set of flows suitable for web applications, mobile devices, and game consoles.

Performance at Scale

As large providers started using OAuth, the community realized that the protocol does not scale well. It requires state management across different steps, temporary credentials which are more often than not discarded unused, and typically requires issuing long lasting credentials which are less secure and harder to manage (and synchronize across data centers).

In addition, OAuth 1.0 requires that the protected resources endpoints have access to the client credentials in order to validate the request. This breaks the typical architecture of most large providers in which a centralized authorization server is used for issuing credentials, and a separate server is used for API calls. OAuth 1.0 requires the use of both set of credentials: the client credentials and the token credentials which makes this separation very hard.

So What’s New?

The following is a subset of the new features available in OAuth 2.0:

6 New Flows

  • User-Agent Flow – for clients running inside a user-agent (typically a web browser).
  • Web Server Flow – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.
  • Device Flow – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.
  • Username and Password Flow – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password.  This flow is only suitable when there is a high degree of trust between the user and the client.
  • Client Credentials Flow – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.
  • Assertion Flow – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.

Native application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.

Bearer tokens

OAuth 2.0 provides a cryptography-free option for authentication which is based on existing cookie authentication architecture. Instead of sending signed requests using HMAC and token secrets, the token itself is used as a secret sent over HTTPS. This allows making API calls using cURL and other simple scripting tools without having to canonicalize the request and sign it.

Simplified signatures

Signature support has been significantly simplified to remove the need for special parsing, encoding, and sorting of parameters. It also uses a single secret instead of two.

Short-lived tokens with Long-lived authorizations

Instead of issuing a long lasting token (typically good for a year or unlimited lifetime), the server can issues a short-lived access token and a long lived refresh token. This allows clienta to obtain a new access token without having to involve the user again, but keeps access tokens limited. This feature was adopted from Yahoo!’s BBAuth protocol and later its OAuth 1.0 Session Extension.

Separation of Roles

OAuth 2.0 separates the role of the authorization server responsible for obtaining user authorization and issuing tokens from that of the resource server handling API calls.

When is it coming out?

OAuth 2.0 is currently in development by the IETF OAuth Working Group. The latest draft is considered stable but with many features being changed or added. Partial support is already available from Facebook and Twitter. The final specification is expected by the end of the year.

30 thoughts on “Introducing OAuth 2.0

    • You cannot run an OAuth provider, 1.0 or 2.0, without SSL and expect it to be secure. The reason for that is that you have to send the token and secret to the client somehow, and if you send them in the clear, they can be captured. Note that this requirement is only for obtaining a token. Once you have a token, you can use signatures instead of SSL, or use short-lived bearer tokens to reduce risk when sent over non-secure channels.

      But sending secrets in the clear without a secure channel is simply broken. You can run it (there is no specification police) – I just would not recommend it.

    • OAuth 2.0 builds on top of the WRAP and Session Extension work. The Session Extension specification draft applies to OAuth 1.0 and is no longer needed with 2.0. As for WRAP, I would hope (and expect) it to fade away as OAuth 2.0 incorporates all it has to offer in a cleaner, richer way. But that’s a decision for the WRAP community which I am not a member of.

  1. OAuth 1.0 requires the hostname in the base string, and it appears to be the same in the 2.0 draft. This complicates the use case of a proxy service, as a number of libraries don’t allow for signing the request for one destination and sending it to another.

    Great design removes the inessential. How does the hostname appreciably improve either message integrity or authentication?

    • Removing the host name allows an attacker to reuse the signed request against a different host using the same token (if that’s how the provider deployed their service). I agree it is unusual. If you feel strongly about it, join the working group and bring this up.

  2. Hello I need the .dll file for oauth latest version oauth1.0.0 for windows php. Have you any ideas for it

  3. Do you know if OAuth would address the problems around Cross Site Request Forgery? The whole bearer token and cookie feature sounds like CSRF is still a threat and not mitigated?


  4. Is it possible to have some sort of playground or sandbox to allow developers to get familiar with and possible some classes across diff. languages how spec 1.0 used to have? thanks. and great work btw!!!

  5. The draft seems to make user-agent and callback URI mandatory part of authorisation. Doesn’t this make it difficult to develop applications on mobiles (including iphone/android platform)?

  6. But as long as User Redirection is there , “phishing attack” can not be avoided. So What has been done to address that, as in 1.0a spec it was mentioned like “its beyond scope of this document”. And im confused what can be done ?

    Can you please give your input.

  7. Hello Eran,
    I am developing iPad client for a customer and the server at clint end uses OAuth 2.0, so my question is what is the best flow that I need to choose from available 6 flows for my iPad app?

    • It’s been a long time since I wrote this post. The spec now has two main authorization flows (called grant types) and there is also a section on native applications which you may find useful.

  8. Hi Eran,

    As I’m planning on implementing OAuth on my API server in the coming days, I’d obviously like to implement OAuth 2.0 and not 1.0. My main concern is whether the current draft is stable enough for prime time. How far is it from the final version?


Comments are closed.