The grant type is how OAuth 2.0’s Authorization Server can process and verify that the Client Application is eligible for access to the Resource Server. There are 5 types of grant types that OAuth 2.0 defines in its spec:

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

In this tutorial, we will learn the details of each grant type!

Authorization Code

With this grant type, the Client Application will first request the authorization code from the Authorization Server, then use this authorization code together with the client secret to get the access token. Once the access token is available, the Client Application can use this access token to confirm with the Resource Server about the resource it wants to use. Specifically, the grant type process of the Authorization Code will take place as follows:

OAuth 2.0 Security Best Current Practice recommends us to use this grant type with PKCE https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.1.1. You can see more about grant type Authorization Code with PKCE here.

Implicit

This grant type is similar to the grant type Authorization Code for the most part, except that the Authorization Server will not return the authorization code for the Client Application, but will return the access token as soon as we login to the Authorization Server.

This means the token is not stored securely on the Client Application, now we can see the access token as well.

Specifically, the grant type process using Implicit will take place as follows:

OAuth 2.0 Security Best Current Practice advises us not to use this grant type https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.1.2, use grant type Authorization Code with PKCE instead!

Resource Owner Password Credentials

With this grant type, we have to trust the Client Application completely, because we will have to log in to the Client Application using the credentials in the Authorization Server. The Client Application will then capture our login information.

Only use this type of grant if it’s absolutely necessary, guys!

OAuth 2.0 Security Best Current Practice advises us not to use this grant type https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-3.4

Client Credentials

This grant type is used for Client Applications that can get access tokens without going through the user. We will use a pair of client ID and client secret to do this.

Refresh Token

In OAuth 2.0, we use the access token to verify requests from the Client Application to decide if this Client Application is allowed to access resources or not? An access token has an expiry date to use and when it expires Client Application must get new access token to be able to continue requesting resources.

One problem with the Authorization Code grant type is that every time we want to get a new access token, we need the user to log in. OAuth 2.0 introduces a concept of refresh token, so that we do not need to have a user logged in to get the access token. Every time the Authorization Server issues an access token for the Authorization Code grant type, it will include a refresh token. You just need to use this refresh token with the client ID and client secret to get the new access token without having to follow the steps required of the Authorization Code grant type including the mandatory user login.