What is OAuth 2.0 ? How it Works ? A Detailed Explanation of Authorization Framework

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006.

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

OAuth 2.0 Earlier Practices

Fig.1 Simple Form Based Authentication

Disadvantages-

Ensuring security of each login activity
Maintaining the forms , hashing algorithms , cookies , session variables etc.

2. Single-Sign-On : SAML (Security Assertion Markup Language)

Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions.

3. Delegated Authorisation

Allowing other websites to access a resource owner’s data stored in some other website without giving the Password.

Earlier Solutions for Delegated Authorization

1. Yelp

This is an example in which Yelp wanted to solve the issue of delegated authorization and incorporated a method with which a user could let Yelp access some part of his/her data from his preferred mail ID by entering their mail ID and Password for the same.

Fig.2 Delegated Authorisation in Yelp

2. Facebook

This is an example in which Facebook wanted to solve the issue of delegated authorization and incorporated a method with which a user could let Facebook access some part of his/her data from his preferred mail ID by entering their mail ID and Password for the same.

Fig.3 Delegated Authorisation in Facebook

Issues with Earlier Solutions

In the shown cases, a user will have to just trust Yelp or Facebook and believe that they keep his/her mail ID and password safe and also that they do not access any other information except what they asked for.

These were insecure and bad ways to implement delegated authorization and left the user’s credentials as well as his/her account at risk always.

Solutions for Delegated Authorization Today

Fig.4 Solutions for Delegated Authorisation Today

In the given example, the user is asking Google to allow Yelp/Facebook to access only his contacts using Google APIs.

Here, after authenticating the user, Google API will grant access of the user’s contacts to Yelp/Facebook.

A Real Life Example

The following are real-life examples that involve a secure implementation of delegated authorization.

Here, Spotify wants to access some of the user’s Facebook data.

Fig.5 Spotify accessing some of the user’s Facebook data

OAuth 2.0 Terminology

To analyse OAuth 2.0, Taking an example of a user trying to login into LinkedIn using Gmail(Google) API and credentials-

Resource Owner: The user who is interacting with the application (the user owns the data the application wants to get to)
Client: The application with which the user is interacting directly (LinkedIn)
Authorization Server: The server which is used to Authorize the request sent by the client for the user’s data (Gmail)
Resource Server: The API or the system that actually holds the client’s data (Gmail API )
Authorization Grant: The entity that proves that permission is granted to the client by the Authorization Server
Redirect URI: After the Authorization Grant is given by the Authorization Server , it is sent to the client , to the callback address provided by the client, this callback is sometimes known as Redirect URI
Access Token: It is the key used by the client to access the resources it has been granted access to , at the Resource Server

Channels

There are two types of channels by which the whole process occurs.

Front Channel: It is the initial (not so secure) channel between the user’s browser side client and the Authorisation Server.
Back Channel: It is the highly secure channel between the Client’s Server and the Authorization Server and the Client’s Server and the Resource Server.

Client Types

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., the ability to maintain the confidentiality of their client credentials):

Confidential: Clients capable of maintaining the confidentiality of their credentials (e.g., the client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

Public: Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

Protocol Endpoints

The authorization process utilizes two authorization server endpoints (HTTP resources):

Authorization endpoint — used by the client to obtain authorization from the resource owner via user-agent redirection.

Token endpoint — used by the client to exchange an authorization grant for an access token, typically with client authentication.

As well as one client endpoint:

Redirection endpoint — used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.

Simple Representation of OAuth 2.0 in Action

Fig.6 Simple Representation of OAuth 2.0 in action

Steps:

Yelp/Facebook wants to access the user’s Gmail contacts, so they give the option to do so using Google’s API
As soon as the user clicks on Connect with Google, he is redirected to a google endpoint where he is asked to enter his gmail credentials (Authentication)
When the Authentication is successful, the user is asked whether he wants to allow Yelp/Facebook to access his data or not
If the user clicks on Yes, he is redirected back to Yelp/Facebook, and Yelp/Facebook is given access to his contacts.
If the user clicks on No, the access request is terminated.

We can see that the process in which Yelp/Facebook accesses Gmail contacts has dotted lines, which implies that it takes place via the Back Channel.

The solid lines represent the Front Channel.

OAuth 2.0 Authorisation Grant

An Authorisation Grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token.

It has the following types:

1. Authorisation Code

The authorization code is obtained by using an authorization server as an intermediary between the client and the resource owner.

Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server via its user agent, which in turn directs the resource owner back to the client with the authorization code.

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization.

Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.

2. Implicit

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript.

In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.

When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client.

3. Resource Owner Password Credentials

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client, and when other authorization grant types are not available.

4. Client Credentials

The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.

Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.

OAuth 2.0 Access and Refresh Tokens

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client.

The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).

Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token.

A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client.

The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.

Obtaining Authorisation Example: Authorisation Code Grant

Fig.7 OAuth 2.0 in Action

Steps:

Yelp/Facebook wants to access the user’s gmail contacts, so they give an option to do so using Google’s API.
As soon as the user clicks on Connect with Google , he is redirected to an Authorisation Server where he is asked to enter his gmail credentials (Authentication). This request also contains the Redirect URI , Response Type and Scope of the request.
When the Authentication is successful, the user is asked whether he wants to allow Yelp/Facebook to access his data or not.
If the user clicks on Yes , he is redirected back to Yelp’s/Facebook’s Redirect URI, along with an Authorisation Code.
If the user clicks on No , the access request is terminated.
Yelp’s/Facebook’s Server then exchanges the Authorisation Code with the Authorisation Server, and in response, is given an Access Token by the Authorisation Server.
Yelp’s/Facebook’s Server then sends the data access request to the Resource Server along with the Access Token, and in response, is given access to the data in scope.