Reduce Password Proliferation.. OAuth 2.0 is your friend.. - Part 2

This is a continuation from the Part 1 of my post in the same topic. I would suggest reading the previous part before embarking on this post.

I had a good read of your previous post.. Now, take me through how different is the OAuth 2 route as against the 'Password Anti-Pattern' Route..

 Alright...Taking the example of the Mail Aggregation website (KoolAgg) we discussed earlier,

1. The Resource Owner (the end-user) delegates the authority to the Client (eg: KoolAgg) to make API calls to the Resource server (GMail Mail Server). 
2. KoolAgg (assuming its registered with Google as mentioned in the pre-requisites), sends an authentication request passing its ClientID, Scope required and a RedirectURL. The user is presented with a page from the Google Server requesting grant of access (User Consent) and in the event of a Grant from the user, redirects request back to the browser with the “Authorisation Code”.
3. The client again sends a fresh request with the “Authorisation Code” along with its ClientID and RedirectURL to the Google Auth server to exchange it for an “Access Token”. 
4. The Google Auth Server on successful validation sends back a response to the RedirectURL with an “Access Token” and optionally a “Refresh Token”. 
5. The client then calls the Google mail API in the resource server armed with the “Access Token” to retrieve the emails from Google which it can aggregate after performing a similar operation on the Yahoo Server too.

Great.. I am now getting a hang.. That’s a lot of Token types going around isn’t it? A bit more detail on these and the other terminologies might be of help.

 The “Access Token” is used by clients to make authenticated requests on behalf of the Resource Owner to the Resource Server. The Access Token can grant access to multiple APIs (which boils into features). The set of features that is permitted to be granted access is controlled by a parameter called “Scope”. The value and meaning the scope parameter is defined by the Authorisation Server. This parameter needs to be sent with one or more values as part of the Access Token request sent to the Authorisation Server. Access Tokens are valid only for the set of operations and resources as set in the scope of the token request. This is enforced by the Resource Server. This is the reason the Access Token is often equated to a “Valet Key” which only allows you to perform a limited set of functions (scope) and is time bound (access duration) unlike a full key.

Access tokens have a definitive lifetime that is often shortlived, which means that if the Access Token expires, the user would need to perform all the procedures that he did earlier for the access token to be provided. This can affect the user experiance. At the same time it is not safe to have a long lifetime for Access Token since in the event of a compromise, it can lead to a higher exposure. To arrive at a balance between the security and usability aspects, Refresh Tokens were introduced. Hence if access to the API is needed for more than the lifetime of a single access token, a Refresh Token can be used.

Refresh tokens are tokens used by client to obtain new Access Token without having to involve the Resource Owner. In most implementations Access Tokens cannot be revoked (hence the short life) but the Refresh Tokens can be revoked. Refresh Tokens tend to have a longer lifetime than Access Token. Similar to the Access Token, the user would need to perform the authentication process again when the Refresh Token expires. Hence it is a good practice from a Security perspective to set an appropriate expiry time for the Refresh Token.

When an Access token expires, the application can provide the Refresh Token to the application server  and recieve another set of fresh Access token and Refresh Token to use the next time. This provides the option to implement any changes in the Access Token policy (eg: Altering its lifetime or Scope) transparent to the application.

Brilliant.. How about the same usage on mobile devices etc ??

In the case that our aggregation service is an app on your mobile phone, then a browser window would pop-up for the Resource Owner to provide the Grant (User Consent). The OAuth token would be stored in the mobile phone to prevent the need for the user to perform the granting every time the app is opened. Also, it can eliminate the need for storing passwords on the mobile phone. In the event that the mobile phone is stolen, user could simply revoke permission for that app on the mobile without affecting other means of access.

I think i’ve touched upon most of the important aspects of OAuth 2.0 and covered the "Authorisation Code" access pattern (which is by far the most common and also the most secure) in detail. OAuth 2.0 also supports other types of access patterns which are also called "Grant Types" (eg: Implicit Grant, Resource owner credential, Client credential etc.) which have not been covered in this post for the sake of brevity. That is for a different day.

Further details on OAuth 2.0 specification can be found here.

#KillPassword