Grant Types or Flows
In this article, we’re diving into the different grant types or flows utilized in obtaining an access token. While some methods vary and others bear close resemblance, their differences often hinge on whether a user is involved and whether confidential data can be securely stored within an application without unauthorized access. It’s important to note that the authorization server facilitates this through specific endpoints, including the authorize and token endpoints
Client Credentials Grant Type or Flow
This mechanism acquires an Access Token outside of the user context, meaning no user involvement is necessary, making it ideal for application-to-application interactions, such as between back-end applications. Here, the client itself is the resource owner.
How It Works:
1-The Client ID and possibly the client secret are securely stored within the client.
2-These credentials are then sent to the resource server at an “authorize” endpoint, specifying the grant type, client ID, client secret, and requested scopes.
3-An access token is returned, which has a limited lifespan before expiration. Upon expiration, a new access token can be requested.
4-This access token is then sent to the resource server, which validates it and returns the requested protected resources.

Usage:
Primarily utilized between back-end applications.
Legacy: Password Grant Type or Flow
This older method is considered insecure as it fundamentally relies on a user being present, with the username and password being transmitted. This method is used with public clients.
How It Works:
1- The client stores the client ID and client secret.
2- The end-user (or resource owner) opens the application through the client.
3- The client requests credentials from the user, who enters their username and password.
4- These credentials, along with the specified grant type, scopes, username, and password, are sent to the resource server.
5- The resource server verifies the user’s information and returns an Access Token.
6- The client stores this access token and uses it to access the protected resources from the resource server.
Usage:
Previously employed in front-end applications.
Drawbacks:
Lacks security and is vulnerable to hijacking.
Legacy: Implicit Grant Type or Flow
Also designed for use with public clients and operates in the presence of a user.
How It Works:
1- The client retains the client ID and client secret.
2- The user opens the client, which redirects to the authorization server.
3- The authorization server requests the user’s username and password.
4- After the user inputs these credentials and grants permission to the client for data access, the authorization server redirects back to the client with an access token in the response.
5- The client then uses this access token to request protected resources from the resource server, which allows access.
Usage:
Employed in front-end applications.
Drawbacks:
This method offers weak security but is slightly better than its predecessor, still vulnerable to hijacking.
Authorization Code Grant Type or Flow
This mechanism, used by public clients, is often preferred over the implicit grant-type flow for its enhanced security.
How It Works:
1- The client stores the client ID and client secret.
2- The application or client redirects to the authorization server’s authorize page, sending data like the Redirect Uri, client ID, and the desired response type, typically “code”.
3- The authorization server requests the resource owner to enter credentials and grant permissions to the client.
4- Upon the user’s consent, an authorization code is created.
5- The authorization server redirects back to the client using the previously sent Redirect Uri, with the authorization code.
6- The client then uses this authorization code to request an access token from the authorization server via the token endpoint, specifying the grant type as “code”, along with the authorization code, client ID, and client secret.
7- The authorization server validates and returns an access token, which the client uses to request and receive protected resources from the resource server.
The following diagram shows how it works, but with native app and native client.
Usage:
Used instead of Implicit Grant-Type with Front-End and Native client like Bobile app and Desktop app.
Authorization Code with PKCE Grant-Type Flow
Short for Proof of Key Code Exchange, this mechanism enhances the previous method by adding a layer to mitigate hijacking risks.
How It Works:
1-The client keeps the client ID and client secret.
2- The application or client creates a verifier code and challenge code, then redirects to the authorization server’s authorize endpoint containing the code challenge.
3- In the request, data such as the Redirect Uri, client ID, and the response type, typically “code”, are sent.
4- After the user enters their credentials and grants permission, an authorization code is generated.
5- The authorization server redirects back to the client, which then uses the authorization code to request an access token, specifying the grant type as “code”, along with the authorization code, client ID, and client secret.
6- The authorization server evaluates the code verifier (a step not present in the previous method) before validating and returning an access token.
7- The authorization server validates and returns an access token, which the client uses to request and receive protected resources from the resource server.
This enhanced mechanism offers a more secure method for managing authorization in modern applications, especially in scenarios vulnerable to hijacking.