Understanding OAuth

What is OAuth?

OAuth is an open standard for authorization which is an alternative to the password anti-pattern. OAuth provides client applications a ‘secure delegated access’ to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party client access to their server resources without sharing their credentials. The third-party client can be a Web Application, Mobile App, Browser App, Desktop Client or a trusted Application. To explain this in simple terms, lets say you are a user of Facebook and you try to play a game (third party app), which requires access to some of your information and access to post to wall etc. Before the advent of OAuth, the user would have been required to give his Facebook username and password details to the third party app. OAuth allows to do this without you having to provide your Facebook username and password to the third party app.

In the traditional client-server authentication model, the client requests an access restricted resource (protected resource) on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third-party. This creates several problems and limitations.

1. Third-party applications are required to store the resource owner’s credentials for future use, typically a password in clear-text.

2. Servers are required to support password authentication, despite the security weaknesses created by passwords.

3. Third-party applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.

4. Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties, and must do so by changing their password.

5. Compromise of any third-party application results in compromise of the end-user’s password and all of the data protected by that password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner.

OAuth History

Large social providers like Facebook, Yahoo!, AOL, Google  each started developing their own alternative to the password anti-pattern. The community decided to standardize the specification and OAuth 1.0 was published as an RFC (RFC 5489). In 2010, an attack on OAuth 1.0 was identified which relied on an attacker initiating the OAuth authorization sequence, and then convincing a victim to finish the sequence  (session fixation attack) – a result of which would be the attacker’s account at an (honest) client being assigned permissions to the victim’s resources at the Service Provider. OAuth1.0 has been officially deprecated on April 20, 2012 due to security flaws .There were other issues like the complexity of the signing process and the support for different client types which made OAuth1.0 a little difficult to use.

Then came a revised version of OAuth 1.0 which has been called OAuth 1.0a which addresses the security issue in OAuth 1.0 but the complexity of the signing requests and the support for different client types remained as is. Some of the major Service Providers on OAuth1.0a include Twitter, Flickr, MySpace, Linkedin (also on OAuth2.0) etc.

In 2010, Microsoft, Yahoo!, and Google created the Web Resource Authentication Protocol (WRAP), which was soon submitted into the IETF WG as input for OAuth 2.0. WRAP proposed significant reworking of the OAuth 1.0a model.

OAuth 2.0 attempted to replace 1.0a with a simpler protocol but its more of a framework. The onus of security falls into the hands of the providers and the client developers who are implementing the specification. There have been a lot of concerns with OAuth 2.0 security Read more. Some of the major Service Providers on OAuth2.0 include Facebook, Google, Amazon, AOL, Box, bitly, Github, Instagram etc.

Development of OAuth 2.0 in the IETF consequently reflects the input of both OAuth 1.0, OAuth 1.0a, and the WRAP proposal. It is fair to say that the very different assumptions about what are appropriate security protections between OAuth 1.0a and WRAP have created tensions within the IETG OAuth WG.

While OAuth 2.0 initially reflected more of the WRAP input, lately (i.e. fall 2010) there has been a swing in group consensus that the signatures of OAuth 1.0a that were deprecated by WRAP are appropriate and desirable in some situations. Consequently, signatures are to be added back as an optional security mechanism.

While many deployments of OAuth 1.0a survive, more and more OAuth 2.0 deployments are appearing – necessarily against a non-final version of the spec. For instance, Facebook, Salesforce, and Microsoft Azure ACS all use draft 10 of OAuth 2.0.

OAuth Terminology

Below is the list of terms often encountered in OAuth 1.0a specification.

Term Explanation
Service Provider A web application that allows access via OAuth.
User An individual who has an account with the Service Provider
Consumer A website or application that uses OAuth to access the Service Provider on behalf of the User
Protected Resource(s) Data controlled by the Service Provider, which the Consumer can access through authentication
Consumer Developer An individual or organization that implements a Consumer
Consumer Key A value used by the Consumer to identify itself to the Service Provider
Consumer Secret A secret used by the Consumer to establish ownership of the Consumer Key
Request Token A value used by the Consumer to obtain authorization from the User and exchanged for an Access Token
Access Token A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the Users Service Provider credentials
Token Secret A secret used by the Consumer to establish ownership of a given Token
OAuth Protocol Parameters Parameters with names beginning with oauth_ which are passed in the Authorization request header
Request Token URL The Service Provider endpoint that the Consumer uses to get an unauthorized request token
User Authorization URL The URL used by the Service Provider to obtain User authorization for Consumer access
Access Token URL The Service Provider endpoint that the Consumer uses to exchange the authorized Request Token for an Access Token

Below is the list of terms often encountered in OAuth 2.0

Term Explanation
Server A web application that allows access via OAuth.
Resource Owner An individual who has an account with the Server
Client A website or application that uses OAuth to access the Server on behalf of the Resource Owner
Protected Resource(s) Data controlled by the Server, which the Client can access through authentication
Client Developer An individual or organization that implements a Client
Client Id A value used by the Client to identify itself to the Server
Client Secret A secret used by the Client to establish ownership of the Client Id
Access Token A value used by the Client to gain access to the Protected Resources on behalf of the Resource Owner, instead of using the Owners Server credentials
Request Token A value used by the Client to get exchange the Access Token for a new one in case of expiry
Token Type The type of access token issued by the Server
Grant Type A value used by the Client to authorize access to protected resources in various ways with different security credentials

OAuth – High Level Overview

OAuth defines three roles: client, server, and resource owner. These three roles are present in any OAuth transaction (3-legged); in some cases(2-legged) the client might be the resource owner or might act on behalf of the resource owner. We will look at these scenarios in the later sections. The 1.0 specification used a different set of terms for these roles: consumer (client), service provider (server), and user (resource owner).

OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. The client then uses the access token to access the protected resources hosted by the resource server. OAuth is commonly used as a way for web surfers to log into third party clients using their Microsoft, Google, Facebook or Twitter accounts, without worrying about their access credentials being compromised. For example, a twitter app called TweetGif was hacked, releasing user information (does not include passwords) for 10,000 Twitter accounts to the public. However, no Twitter credentials were compromised, because Tweetgif was using OAuth access tokens for authorization and had access to only basic user information.

2-legged and 3-legged OAuth

How OAuth Works?

Lets say you are a user with a Facebook account and you play FB games (lets say Farmville). Farmville posts updates to your Wall so that your friends know your scores. In order to do so, you need to give the thrid party Farmville App access to some of the resources of your account (basic information, access to post to wall), so it can get your info and post to your wall on your behalf. In the old days, you would have to give an app like Farmville your Facebook username and password, so it could log in and access those services. You not only had to trust them to use those credentials wisely, but also to keep them safe from hackers—that’s a pretty big leap of faith. It’s like giving your house keys to a stranger and trusting them not to make copies for all their friends and steal all of your stuff.

OAuth gets around this problem by only giving them access to the stuff you want them to access. Instead of asking you for your password, this happens:

  1. In order to become a Facebook app, Farmville should acquire two tokens from Facebook service: a “Consumer Key” and a “Consumer Secret” that Facebook can use to uniquely identify the Farmville App. These are what create a connection between the consumer (in this case, Farmville) and the service provider (in this case, Facebook).
  2. When user visits the Farmville app (on zynga.com) , he gets an option to play on facebook. When a user clicks on it, he is redirected back to Facebook. If the user isn’t logged in to Facebook, he will be prompted to login (remember, user is giving his username and password to Facebook itself, not to the third party Farmville App).
  3. Facebook then asks you whether you want to authorize this app, and tells you what permissions its giving to the app. Maybe it can view your timeline, or maybe it can view your timeline and post on your behalf. In some cases, you may only be giving it access to your username and avatar. When you click the “Authorize” button, it creates an “Access Token” and an “Access Token Secret”. These are like passwords, but they only allow Farmville to access your account and do the things you’ve allowed it to do.

Step1: User goes to zynga to play farmville

farmville1

Step2: User clicks on Play on Facebook button and is redirected to Facebook login

farmville2farmville3Step3: Facebook asks user for Authorization to allow Farmville app to access some info

farmville4

farmville5

Step4: After user authorizes, he is redirected to the Farmville app

farmville6

Authentication Flow in OAuth1.0a

The authentication in OAuth1.0a involves four steps:

  1. The Consumer obtains an unauthorized Request Token.
  2. The User authorizes the Request Token.
  3. The Consumer exchanges the Request Token for an Access Token.
  4. The Consumer uses the Access Token to access protected resources.

The detailed authentication flow can be seen in the figure below.

oauth1_0aThe request and response in each step are as follows

OAuth 1.0aNote that these request parameters are sent in the Authorization Request Header. For example, the request might have an Authorization header like

Authorization: OAuth realm=”http://sp.example.com/”,
oauth_consumer_key=”0685bd9184jfhq22″,
oauth_token=”ad180jjd733klru7″,
oauth_signature_method=”HMAC-SHA1″,
oauth_signature=”wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D”,
oauth_timestamp=”137131200″,
oauth_nonce=”4572616e48616d6d65724c61686176″,
oauth_version=”1.0″

The process for generating the signature can be found in detail here.

Differences between OAuth1.0a and OAuth2.0

OAuth for various scenarios

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s