Home » Others » Explore Technology

OAuth 2.0 — The All-New OAuth Flavour

Posted by Prashant Tiwari | Sep 01, 2011 | (0) | Add a Comment  |   Bookmark and Share
Since its formulation, OAuth has been the authentication protocol of choice for the web, with all the major web identity and service providers adopting the standard enthusiastically and baking the necessary functionality into most of their web services quickly. For instance, Twitter — arguably the most popular API on the web — deprecated access to its data through its Basic HTTP Authentication in 2010 and announced exclusive OAuth-support.

It was good tidings for users wary of sharing their login credentials with non-trusted websites and applications, for they could now explicitly choose to allow which 3rd-party sites may securely access their data on their behalf without giving away their passwords. (And if you’re one of the majority of internet users who don’t mind using their Gmail account password across their work email and online banking accounts as well, you now had every reason to cheer!) It was also a good thing for the internet as developers could leverage the enhanced perception of security around the APIs to build newer and more innovative applications around them, helping the ecosystem grow and thus ultimately driving the web forward.

However, despite its wide adoption, OAuth — officially titled OAuth 1.0, with a subsequent revised named OAuth 1.0a — was far from easy or intuitive to use. Although it was intended to be used across all platforms, the OAuth flow came to be primarily useful only for server-to-server communications and in-browser web applications, while the usability suffered badly on desktop environments, mobile devices, and other embedded systems. Another major technical issue is that the OAuth specification has left the implementation details to the library developers to work out, because of which web services often need to improvise around the protocol, ending up with varying solutions to similar problems. In the process, standards are sometimes violated, leading to a poorer and less-secure implementation.

In the meantime, some OAuth experts came up with a new proposal to simplify OAuth, resulting in what came to be known as OAuth WRAP. However, WRAP never matured and didn’t quite take off. That’s when the IETF OAuth Working Group consisting of representatives from Google, Facebook, Yahoo, Microsoft and others set itself to the task of improving the OAuth developer and end-user experience and began work on OAuth 2.0. Although it’s still under development (currently in its 20th revision), we’ll take a look at some of the many improvements OAuth 2.0 proposes to offer.

OAuth 2.0 supports the following 3rd-party client profiles that can request access for user data, depending on whether they are inherently capable of keeping the user credentials secure (“confidential”) or likely to easily expose them to the outside world (“public”):
1. Web Applications (aka server-side applications) — clients running within a secure web server,  
    hence purely “confidential”.
2. User-Agents (aka client-side applications) — typically web browsers that can download the
    client code on the user’s device, hence highly secure.
3. Native Applications — applications installed on the user’s personal computer or mobile device,
    hence possibly exposed to be compromised.

If you’re familiar with OAuth, you will recognise that these profiles were already supported even before, however inelegantly, and OAuth 2.0 retains that support for the following authentication flows:
User-Agent Flow — the most common OAuth flow, meant to be used inside web browsers.
Client Credentials Flow — similar to the less common 2-legged OAuth approach.

However, according to Eran Hammer-Lahav, one of lead authors of the spec, what OAuth 2.0 proposes to distinguish itself from its previous avatar is its support for 4 distinct new flows, aiming to explicitly cover the following scenarios that were mostly hard to do before:
Device Flow — an improved flow for mobile and other emerging web-enabled devices.
Web Server Flow — for clients sitting on web servers.
Assertion Flow — exchanging valid SAML assertions for an OAuth token.
Username and Password Flow — seemingly an un-OAuth-like fallback to situations in which the     
   raw user credentials must be provided to a trustworthy client that still only gets to keep the OAuth
   oken generated from the supplied credentials.

Since the new spec is not backwards compatible with version 1, most web service providers are still to add support for it in their APIs, perhaps because the spec hasn’t yet been formalised and is still evolving. As of this writing, only Facebook, Google and Microsoft among the major players have announced support for the new authentication flows for a select few APIs. We can expect to see a much larger adoption as the standard matures.

In the following posts, we’ll discuss the proposed OAuth 2.0 architecture in more detail with an example of how to use it in the real world.

0 Comment for this post

Post a Comment

Required Information *
Name* Email*


In accordance with our comment policy, we encourage comments that are on topic, relevant and to-the-point. Once submitted, your comments will be published by the Impetus blog moderator. We will remove comments that include profanity, personal attacks, racial slurs, or threats of violence, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.