Hey there, Welcome back! In our previous blog, we have learnt how OAuth works in general along with the key components holding this framework together. In this blog, we gonna dive a bit deep and find out different types of authorization grants defined in the standard. Let’s jump in.

Authorization Grant & Types

Authorization Grant represents the consent of the user to allow a particular client to access one or more of it’s protected resources. The client can use this grant to exchange for an access token, & use it to access those protected resources.

There are four types of Grants defined in the OAuth spec.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

Authorization Code

Authorization code flow is one of the widely used flows and is considerably secure than the other flows. So, what’s in it?

This grant involves an intermediary between resource owner and the client which is called as an authorization code.

When client initiates an OAuth flow with this grant, the client redirects the resource owner to the authorization server, where user authenticates himself/herself & then authorizes the client to do certain actions on his/her behalf.

Now, the authorization server creates an authorization code with all the scopes allowed by the user, and redirects to the callback handler of the client, where the auth code is exchanged for an access token.

In this flow when a request is made, grant_type is set to authorization_code.

With this flow, we achieve the motto behind OAuth, to not expose the user credentials to a third party client, to authenticate the clients & also the access token being issued to a specific client.

Implicit

Implicit flow is particularly used for browser based clients, where they look at reducing the number of round trips need to be made to get the access token.

But, this comes with lot of security considerations, as the token is returned as part of an URL fragment back to the client’s redirection URI, which is prone to be stolen.

In this flow when a request is made, grant_type is set to implicit.

When you look at using this flow, to get an access token you must take additional security checks after getting it. For e.g.: Check if the token is issued to you, using audience claim (we will talk more of this in upcoming blogs).

We should use this flow only in trusted environments.

Resource Owner Password Credentials (ROPC)

This is one flow, which is deprecated now due to the security implications it brings in. However, let’s look at how it works.

The user enters in his/her credentials on a client page, which then without storing, will get exchanged for a long-lived access token with the authorization server, or can also request a refresh token(sounds new? will know more in detail about this in upcoming blogs!) along with the access token, which it can exchange for access token in future.

It’s always recommended to use MFA(Multi Factor Authentication) when using this grant, for a user to acknowledge that a session is being created using his/her credentials.

In this flow when a request is made, grant_type is set to password.

This access token will be sent along with the request to access protected resources from the resource server.

Client Credentials

Remember this question in our previous blog? What if, a client wants to access resource of another software (kind of machine to machine communication)?

Here’s it, this grant answers our question, where the resource owner and the client are the same entity in this scenario.

As you’re already aware of, every client registered with the Authorization server is issued a set of credentials, with which it can authenticate. Now, the client will exchange these credentials with grant_type set to client_credentials.

Looking at the grant type, the authorization server knows that it need not redirect any user and just authenticates the client to issue an access token.

Now, the client will exchange this access token with resource server to access the protected resources in it.

Conclusion

These are grants defined in the OAuth standard, however OAuth provided flexibility to add more. For example, Auth code with PKCE(Proof Key for Code Exchange) is widely used in case of public clients to ensure more security.

Let’s discuss more of it & the standard OAuth endpoints in our upcoming blogs. Before we conclude, give this a thought!

How does authorization server know where to send the authorization code/access token back in case of Auth code and implicit grants?

Post us your thoughts in the comments. We will answer this in our next blog. Until then, stay safe. Cheers ✌️✌️