Tag Archives: OAuth

OAuth 2.0

OAuth 2.0 has been derived from OAuth 1.0. The OAuth 2.0 was introduced to remove the complexities involved with encryption of the requests for tokens that were present in OAuth 1.0 and also to make it more scalable. Some of the OAuth 2.0 providers are Facebook, Google, Amazon, Github, Microsoft, Paypal, etc. With the introduction of OAuth 2.0, OAuth 1.0 has become obsolete.

User and their roles in the system :

Here there are four users in the system, as opposed to only three in OAuth 1.0. They are follows :

  1. Resource server (same as OAuth 1.0) – A website that is capable of storing resources of users.
  2. Resource owner (same as OAuth 1.0) – An entity who wants to store his resources and can provide access to them to other entities.
  3. Client (same as OAuth 1.0) – A application or website that wants to access the resources of the resource owner, on his behalf.
  4. Authorization server – A server that provides temporary intermediate credentials  to the client, that are required in the complete process of providing authorization to the client.
How is it different from OAuth 1.0 ?

It is different in the sense that, while in OAuth 1.0 there was only one server, that is the resource server, wherein the end user (resource owner) could store his resources, in OAuth 2.0, there is one extra server in addition to the resource server – the authorization server. The authorization server is responsible for providing temporary credentials to the client that wants to access the protected resources of the resource owner. OAuth 2.0 provides for better organization and separation of responsibilities among the users of the system.

Workflow :

The following diagram that has been taken from RFC 6749 shows the workflow in the case of OAuth 2.0 .

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

The steps are explained as follows :

  1. The client that wants to access the resource owner’s resources, sends an authorization request to the resource owner.
  2. Authorization is then granted to the client by the resource owner. The authorization can be of different types depending on whether the client contacted the resource owner directly or indirectly.
  3. The client then uses this authorization grant and requests for an access token after it authenticates with the authorization server.
  4. After the authorization server authenticates the client and checks if the authorization grant provided by the resource owner is valid, it provides an access token to the client.
  5. With the access token that it received from the authorization server, the client requests for access to the resources stored in the resource server.
  6. The resource server checks if the access token is valid or not and accordingly provides access to the token.
The concept of Refresh tokens :

The OAuth 2.0 introduces the concept of providing refresh tokens. Refresh tokens are used as a substitute for access tokens that have been issued by the authorization server to the client, when the access tokens expire. When the client makes an authorization grant to the authorization server for the access token, after authentication by the authorization server, it gets back two tokens – an access token and a refresh token. The refresh token can be used instead of the access token in circumstances where the resource server finds out that the access token has expired. This helps continue the process and avoids the issue of creating a fresh access token.

Under normal circumstances (in the absence of refresh tokens) when the access token expires, the process needs to start all over from the beginning. When the client tries to access the resources by providing the access token (that was issued to it by the authorization server) to the resource server, on checking if the resource server find the access token to have expired, the client needs to begin again with requesting authorization to the resource owner and then follow it up with authentication to the authorization server again, and requesting a new access token.

The following diagram, taken from RFC 6749 explains the workflow in the case of refresh tokens.

+--------+ +-------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | |Authorization| | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +-------------+
 Advantages of OAuth 2.0 :
  1. There is a clear separation of roles and responsibilities among the different components of the system.
  2. OAuth 2.0 has support for both native and mobile applications.
  3. It supports various types of use cases depending on whether the client of confidential or public type.
  4. In OAuth 2.0, the client makes requests for tokens over HTTPS and does not require for the requests to be hashed using HMAC.
Disadvantages of OAuth 2.0 :
  1. OAuth is not backward compatible.
  2. Phishing attacks are possible.
  3. The server gets to know more information about the resources owners and clients.
  4. Denial of Service attack is possible on clients and servers.
  5. Replay attack is possible.
References :


OAuth 1.0

OAuth is an open standard for authorization and helps control access to resources that have been stored in a server, by third party users. OAuth is inspired by OpenID. On generalizing the concept of OpenID, we can see that while the OpenID is a special case of OAuth wherein the resources that are shared are only the username and password. Whereas in the case of OAuth, resources could be anything like files / photos.


Let us look at an example scenario. Suppose that Jane (resource owner) has uploaded some of her photos (protected resources) on a website – pictures.com (server). She then wants to print them using another website – print.photos.net (client). However, she does not want to reveal her password to the server, to the client. Under such a circumstance, how does the client access her photos from the server so that it can print them for Jane ?

Naive method : A naive approach would be for Jane to reveal the password to her server, to the client so that the client can also login and access the photos. But that would mean that the client would be able to send request to change Jane’s password on the server. As the server wouldn’t know who sent the password request change, it would comply with the request.

Now this is a problem ! We need a different approach under such a situation. This is where the OAuth comes into play !

Terminology :

Some of the common terminologies used are :

  1. Server : An HTTP server capable of receiving HTTP requests from a client. In the above example, the pictures.com is the server.
  2. Resource owner : The resource owner is the user who has stored some of his resources in a server and can access them using his credentials with which the server authenticates him. Jane is the resource owner, in the explained example.
  3. Protected resource : Something that has been stored in the server by its owner, and to which only limited access is allowed. The protected resource is Jane’s photos.
  4. Client : An HTTP client capable of making HTTP requests to the server. The client in the above example is print.photos.net.
Workflow :

This is how an OAuth supporting website works in the example of Jane :

(Please note that print.photos.net and client, and pictures.net and server, have been user interchangeably.)

  1. Jane (resource owner) has stored her resources in pictures.com (server).
  2. The print.photos.net (client) has signed up for credentials to some of the commonly used servers (among which one is pictures.com) in order to provide better service to users.
  3. Jane wants to print the photos from print.photos.net, the client.
  4. The client needs to establish a set of temporary credentials with the server for which it sends a request for a temporary credential.
  5. The server validates the client request and sends it temporary credentials.
  6. The client redirects Jane to resource owner end of the server.
  7. The server requests Jane to sign in using her credentials that authenticate her with the server and asks her approval to grant permission to the client to access her resources.
  8. Jane approves giving access to client to access her resources.
  9. The client is informed when Jane finishes granting authorization to the client.
  10. The client requests for another pair of credentials to the server, making use of its temporary credentials.
  11. The server again validates the request and sends back a pair of credentials to the client.
  12. The client can now access Janes photos from the server, with this set of credentials recently given to it by the server.

Thus in this manner, the client is authorized to access Janes resources on the server, without Jane having to compromise her password with the client. OAuth workflow

The greatest advantage of OAuth is that it allows third party access to the resources of the user, without the user having to reveal the password. Only just enough permission is granted to the client, to access the user’s resources.

Having said that, the OAuth is not completely secure. A disadvantage of OAuth is that confidentiality is compromised. The tokens that are shared between the client and server are sometimes in plain text.

References :
  1. http://tools.ietf.org/html/rfc5849
  2. https://drupal.org/project/oauth
  3. http://www.ubelly.com/2010/02/building-a-simple-oauth-twitter-application/