OAuth 2.0

What is OAuth:

It is a framework to facilitate delegated and controlled access on behalf of user. So basically, it is a protocol that allows a user to grant a given third-party web site or application access to the user’s protected resources, without necessarily revealing their long-term credentials or even their identity.

There are different flows in which OAuth delegates these accesses but before discussing this let us get acquainted with few of the terminologies.

• Resource Owner: Entity that can grant access to a protected resource. Typically, this is the end-user.
• Resource Server: Server hosting the protected resources. This is the API you want to access.
• Client: Application requesting access to a protected resource on behalf of the Resource Owner.
• Authorization Server: Server that authenticates the Resource Owner and issues access tokens after getting proper authorization. In this case, Auth0.

Pre-requisite – Client registration:

Before initiating the OAuth protocol flow for authorization, the client needs to register itself with the authorization server with following information-

1. Client type: OAuth defines two client types, based on their ability to maintain the confidentiality of their client credentials – confidential and public.
2. Redirection URI: Also called call-back URL to which user is redirected post authorization from auth server.
3. Any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms).

Client Authentication:

Post registration, Auth server issues the registered client

1. Client identifier/Client_id: A unique string, encoded using the “application/x-www-form-urlencoded” encoding algorithm, representing the registration information provided by the client. It is public and unique identifier that represents the client.
2. Client credential/Client_secret: A password, public/private key pair etc. It is used to authenticate the client when it raises request for Access token.

OAuth protocol endpoints:

The authorization process utilizes two authorization server endpoints-

1. Authorization endpoint (auth server base uri + /authorizatin): used by the client to obtain authorization from the resource owner. The request contains a redirection url to which the auth server will redirect the user post successful resource-owner authentication along with an auth code.
2. Token endpoint (auth server base uri + /token)- used by the client to exchange an authorization grant for an access token, typically with client authentication.

OAuth flows:

There are different ways, also called flows, using which OAuth provisions delegation of authorization. And this is governed by the term ‘grant types’. In OAuth, an authorization grant is an abstract term used to describe intermediate credentials that represent the

resource owner authorization. Several authorization grant types are defined to support a wide range of client types and user experiences as below-

1. Authorization code grant (grant_type=’code’):

A few points to note about this flow-

• The exchange of authorization code is done through a front channel which is considered less secure, but the exchange of Access token usually happens through back channel. This also happens to be one of the benefits of this flow over others.
• Resource owner’s user agent is typically a web browser.
• Local state parameter: It is an opaque value used by the client to maintain state between the request and call-back. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery

2. Implicit grant flow (grant_type=’token’):

This grant type differs from Authorization grant flow in skipping the step where Auth server sends Auth code to the client. It instead sends the Access token directly in the redirection URI fragment. The user-agent then requests web-hosted client resource which returns a web page, typically containing HTML and an embedded script capable of accessing the URI fragment retained by user-agent. User-agent then runs this script to extract the access token and return to the client.

3. Resource owner password credential grant (grant_type=’password’):

Here the access token is facilitated in 3 steps as below-

• The request owner provides the client with its username and password
• The client requests an access token from the authorization server’s token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates
  with the authorization server.
• The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.

4. Client Credentials Grant (grant_type=’client_credentials’):

The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control. The client credentials grant type MUST only be used by confidential clients. It has following 2 steps.

• The client authenticates with the authorization server and requests an access token from the token endpoint.
• The authorization server authenticates the client, and if valid, issues an access token.

5. Extension grant:

The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the “grant_type” parameter of the token endpoint, and by adding any additional parameters necessary. Extension grant types are there to support additional clients or to provide a bridge between OAuth and other trust frameworks. Let’s discuss one such grant-type below-

JWT Bearer token grant: This grant type is used when the client wants to receive access tokens without transmitting sensitive information such as the client secret. This can also be used with trusted clients to gain access to user resources without user authorization. Below are the steps to use this OAuth flow: –

1. Create a JWT token by signing it using client’s private key
2. Send request to token end point of authentication server. Ex-

POST /token.oauth2 HTTP/1.1

     Host: https://www.googleapis.com/oauth2/v4

     Content-Type: application/x-www-form-urlencoded

     grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer

     &assertion=<JWT token created in step A>

3. Extract the access token from response