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.
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.
Below is the list of terms often encountered in OAuth 1.0a specification.
|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
|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:
- 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).
- 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).
- 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
Step2: User clicks on Play on Facebook button and is redirected to Facebook login
Step4: After user authorizes, he is redirected to the Farmville app
Authentication Flow in OAuth1.0a
The authentication in OAuth1.0a involves four steps:
- The Consumer obtains an unauthorized Request Token.
- The User authorizes the Request Token.
- The Consumer exchanges the Request Token for an Access Token.
- The Consumer uses the Access Token to access protected resources.
The detailed authentication flow can be seen in the figure below.
Authorization: OAuth realm=”http://sp.example.com/”,
The process for generating the signature can be found in detail here.
Differences between OAuth1.0a and OAuth2.0
OAuth for various scenarios