OAuth 2.0 in a Nutshell

Introduction

OAuth 2.0 is creating a lot of hype in the web service and software industry around the globe. And we often hear many IT products and services adapting to it.

Simply put,

"OAuth 2.0 is a protocol that allows distinct parties to share information and resources in a secure & reliable manner. "
              - Charles Bihis. (2015). Mastering OAuth 2.0

Now a days web applications are used very widely for almost every task. But it is difficult to remember separate credentials to each and every application. This is the basic problem OAuth tries to address.

Best example is where Instagram allows you to login to Instagram using your Facebook account.

This feature is powered by OAuth Protocol.

Before diving deeper into OAuth 2.0 it is important to understand what the following keywords mean.

Authentication - validating if the person is who he says he is.
Authorization - what actions a person is allowed to perform when he / she has been authenticated.

OAuth 2.0 provides,

• Federated Identity

Allowing users to log in to an application with another account.

• Delegated Authority

Allowing another service to access resources on another service on behalf of the user.

OAuth 2.0 alone specifies only authorization. In order to fulfill the Authentication requirement, it combines with OpenID Connect.

The Flow

Before OAuth 2.0, if an application wants to access your data from another application, you have to provide your account credentials, from which the data is to be accessed, to the application who wants to access the data. For example, if an application wants to suggest you your friends from Facebook you will have to provide your credentials of Facebook and then the said application will impersonate you and handle your Facebook account. Not to forget, this gives them full control of the account. That application may even store your credentials. In a time where data security is crucial we cannot simple trust the applications. Therefore they needed a protocol to do this without compromising user's data safety.

OAuth 2.0 overcomes this. If an application, lets say its called 'Sample App', wants to access your friend list, Sample App will ask if you can permit them to access your Facebook friend list. If you grant permission, you will be redirected to a page prompt by Facebook informing you that Sample App wants to access your friend list and asking you if you would want to give your consent to do so. If you allow, Facebook will provide the relevant details to 'Sample App'. This is how OAuth 2.0 works very briefly.

How it works

There are five types of grants specified in the OAuth 2.0 specification. Namely,

-Authorization grant
-Implicit grant
-Resource owner credentials grant
-Client credentials grant
-Refresh token grant

Endpoints

• Redirection Endpoint

This is provided by the Client Application to the service provider. Service provider will send the access tokens etc to this endpoint.

• Authorization Endpoint

This is the endpoint the Client Application should use to initiate the Authorization process.

• Token Endpoint

This is the endpoint the Client Application should use to initiate Token flow.


1. Authorization Grant Flow

1) The application (Client) sends an authorization request to the Auth Server (Authorization
Endpoint).

2) Auth Server requests user for his/her consent for the Application(Client) to access the claims it requests.

3) If the user grants consent, Auth Server provides an Authorization Code grant to the Client Application. (Redirection Endpoint)

4) Client Application sends an Access Token Request to the Auth Server along with the Authorization Code provided previously. (Token Endpoint)

5) Auth Server provides the Access Token (which expires after a specified time period) and Refresh Token to the Client Application to access the claims requested before.

6) If the Access Token expires, Client Application sends a request to the Auth Server (Token Endpoint) along with the refresh token and request for a new Access Token.

2. Implicit Grant

1) This flow will follow the same 1) and 2) steps in Authorization Grant flow but in the Authorization Request it will mention 'token' as the response type, where as in the previous flow it was 'code'.

2) If the user grants consent, Auth Server redirects the user-agent to the redirect URI provided by the Client Application that contains a URI fragment containing the access token.

3) User-agent follows the redirect URI retaining the access token

4) Application sends a script to the user agent that can extract the access token.

5) User-agent runs the script and returns the token to the Application.

3. Password Credentials Flow

In this flow, user will provider his/her credentials directly to the Client Application and it will produce these credentials and request an Access Token from the Auth Server.

4. Client Credentials

Client application sends its credentials (Client ID, Client Secret) in order to obtain an access token and authorize itself to access its own account.

Out of these, the most commonly used ones are 1) and 2).

This specification allows developers to worry less about the authentication and authorization and worry solely about the application logic implementation.

References

[1] - https://tools.ietf.org/html/rfc6749

[2] - https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

[3] - Charles Bihis. (2015). Mastering OAuth 2.0