#2. OAuth 2.0 Flow – Authorization Grants And Their Types

Introduction

I have explained the Flow of OAuth 2.0 in the previous post. In Step B – Receive Authorization Grant, I mentioned that when A Client requests authorization from the resource owner and the resource owner authenticates successfully then an Authorization grant will be received by the Client. We will learn more about Authorization grants and their types in this post.

Learn From My YouTube Video

Video tutorials help in better learning. You must watch the video below. But it is always a good practice to read and understand the articles as well.

OAuth 2.0 Flow Diagram

Authorization Server

The authorization server is an important role in OAuth 2.0 flow which provides an access token to a client by receiving and validating an authorization grant. An authorization server is an intermediary between a client and a resource owner.

Let’s try to understand this with an example. If you want to signup/in on Spotify with your Google account then Spotify navigates you to the Google account page where you need to provide your Google account credentials. This page acts as an authorization server for Google here.

The client needs to register with the authorization server so that the client can direct the resource owner to an authorization server instead of requesting authorization from the resource owner directly.

The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

Authorization Grant

An authorization grant is a credential representing the resource owner’s authorization. The client can use the received authorization grant to get an access token from the authorization server. Once the client receives the access token then it can access the resource owner’s protected resource. So you can understand here that getting the Authorization grant is the starting point.

Types of Authorization Grant

There are four types of Authorization Grants:-

Authorization code
Implicit Grant
Resource Owner Password Credentials
Client Credentials

Authorization Code

The client directs the resource owner to an authorization server. Then the authorization server authenticates the resource owner and obtains authorization. After this client is redirected to the client with an authorization code.

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

An example is as below –

https://localhost:8080/?state=state_parameter_passthrough_value&code=4/0AWgavdfoNkUkCHma6g1lO9-yjKYlJNrYylO7fRE_shjJK1AGLEkZrttKPpXh1Nw5WeYmj7KA&scope=https://www.googleapis.com/auth/drive.metadata.readonly

The authorization code has the ability to authenticate clients and safer transmission of the access token to the client.

Implicit Grant

The implicit grant is a simplified authorization code flow in which an access token is issued directly instead of an authorization code. It is optimized for clients implemented in a browser using a scripted language like JavaScript. The grant type is implicit, as no authorization code is issued.

When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. The access token can be exposed to other applications and resources owner in this flow. But it improves the efficiency and responsiveness of clients as there is no extra step to obtain an access token.

It does not support the issuance of a refresh token.

The Microsoft identity platform supports the OAuth 2.0 implicit grant flow.

Resource Owner Password Credentials

The credential i.e. username and password of the resource owner is used as an authorization grant to obtain an access token. This grant type is suitable where the resource owner has the highest trust level with the client.

The resource owner provides its credentials to the client which is used by the client to obtain an access token from the authorization server. The client must authenticate itself with the authorization server.

So resource owner’s credentials are used a single time to obtain a long-lived access token or refresh token. There is no need of storing the resource owner’s credentials for future use.

Client Credentials

In this type, Client credentials are used as an authorization grant. In the previous type, the resource owner’s credentials are used as an authorization grant. This is useful when the protected resources are under the control of the client or the client is also the resource owner.

Thanks for reading. Kindly comment for any feedback and suggestions.