New Tech 101: OAuth 2.0

New Tech 101: OAuth 2.0

When new technology standards appear in industry publications, we quickly receive inquiries as to the applicability of those standards to their use cases.  So let’s investigate the growing use of OAuth 2.0 in the general industry both from where it began as well as where it appears to be heading at the current time.

Short History of OAuth

OAuth 1.0 was originally developed to answer the problem of integrating a user’s identity information from a resource provider with another provider’s offering.  Social media providers like Twitter drove the development and deployment of OAuth 1.0.  Eventually it was recognized that the 1.0 standard contained limitations from an enterprise point of view.  There also existed implementation flaws such as complex signature generation requirements on top of potential security issues.

Providers such as Facebook began looking at the possibilities of fixing the complexities in the 1.0 standard.  This development led to what would eventually become the 2.0 standard version 1, released in April of 2010.  The changes and additions destined for 2.0 were focused around creating a simpler token sharing method as well as allowing applications (both mobile and desktop) to share tokens outside of web browsers.  As development progressed, the differences between the capabilities of OAuth 1.0 and the plans for 2.0 diverged enough that backwards compatibility between 2.0 and 1.0 became infeasible.

As of the writing of this post, OAuth 2.0 is still considered a draft standard.  With increasing industry buy-in from companies such as Microsoft and Google, the adoption of OAuth 2.0 has become widespread.  There are implementations of OAuth 2.0 in many languages including: Java, Cocoa, Ruby, PHP and Python amongst many others.

The Basics: At its core, OAuth is an authentication scheme to verify the identity of a user using a third party.  The implementation from a conceptual point is not much more complicated than that basic idea.

The Concept: A user wants to login to an application, perhaps your company’s webmail.  You want to verify that the user is who they say they are.  You direct them to get a token from their social media account that they can then provide to your webmail.  The user will login to their social media account and receive a token that will give the application access to a set of protected resources that the user authorizes.  Those resources can be as simple as the user’s personal contact info or even the detailed information of all of their contacts in the social media site.  The user then goes back to the application and passes the token to the application.  The application takes the token and presents it to the social media site.  When the social media site verifies the token, the application now has access to whatever the protected resources may be.

Example: A user wants to import their Facebook contacts into Yahoo! Mail.  They click a button in Yahoo! in the Import section to select Facebook.  The user is then directed to login to their Facebook account.  After successful login, Facebook asks the user if they wish for Yahoo! to have access to their account information.  If the user clicks yes, then Facebook will allow access to the Facebook contacts for that user to Yahoo! Mail.

The conceptual idea and example are illustrations of the first type of OAuth token – an Access Token.

Types of Tokens:

There are two types of tokens: Access and Refresh.  An access token permits exactly that, access to a protected resource for a defined period of time.  A refresh token allows a user to request a new access token after the first token expires.

Ideally, a refresh token is issued to a provider who will need continued access to a protected resource.  So if a provider needs one-time access to a resource, preferably they would only request an access token while providers who need repeated access to the protected resource would have a refresh token and then use that token to obtain access tokens when need be.

Example: Users of social media sites such as Facebook, can often select different apps to do various activities i.e. play games, read horoscopes, etc.  When they choose to initially “install” these apps into their user experience, they have to be logged into their Facebook account.  During that install, they are asked whether they wish to allow the application to access the personal information contained in their account.  Due to the fact that these apps are installed and considered to need repeated access, they receive a refresh token so that when their access token expires, they can request a new one without querying the user again.  When a user goes into their Facebook settings and removes permission to the app, they are telling Facebook to revoke the refresh token.

The basic paradigm is that if you need one time access to a protected resource, request an access token.  If you need repeated access to a protected resource, request a refresh token and then use that token to request access tokens as needed.

OAuth 2.0 and Mobile

As OAuth 2.0 was driven heavily by social media providers like Facebook, Twitter and Flickr, the development of this standard included the possibility of the use of OAuth outside of the strict web browser environment.  The ability to use OAuth tokens in desktop and mobile applications greatly improved the accessibility of OAuth to developers who had not been exposed to OAuth in the web browser environment.  With the backing of large social media providers and the desire of developers to engage those providers, OAuth has started to become an accepted standard in the mobile application environment.  OAuth 2.0 allows mobile applications to request tokens just as web applications can.  This feature allows applications to handle the token request without necessarily spawning a browser window.  The ability to use tokens in an application displays the beginning of true Single Sign On beyond one vendor.  Users are able to only memorize one user/password combination to an authoritative identity source and then provide access to other resources which wish to verify the user’s identity.  The possibilities moving forward in this space certainly excite the imagination.

Note: The specification described above uses the OAuth Working Group v2-30 draft of the OAuth 2.0 standard.  This version of the draft was issued July 15, 2012 and expires January 16, 2013.

Draft located at: http://tools.ietf.org/html/draft-ietf-oauth-v2-30