Understanding OAuth2 Grant Types - DEV Community

OAuth2 is one of the most widely used authorization frameworks in modern applications. However, many developers struggle to understand when to use each grant type and how the flows actually work. In this guide we break down the most common OAuth2 grant types with diagrams and practical explanations.

Overview of OAuth2

OAuth2 is designed to provide a secure way for applications to obtain access to user data without requiring the user to share their credentials. Instead, it uses access tokens issued by an Authorization Server to allow applications to request data from a Resource Server.

What is a Grant Type?

A grant type in OAuth2 is a method by which a client application obtains an access token. It defines the flow that an application follows to request and receive authorization from an authorization server. Different grant types exist to accommodate various security needs and application types.

Grant Types

Authorization Code Grant

The Authorization Code Grant is used by web applications and follows a redirection-based flow to obtain an access token securely.

Steps:

1. The user accesses a web application and is redirected to an Authorization Server for authentication.
2. The user logs in, and if successful, the Authorization Server redirects back to the application with an authorization code.
3. The application exchanges this authorization code for an access token.
4. The access token is then used to request protected resources from the Resource Server.

This flow is ideal for server-side applications where you can securely store the client secret. It provides the highest level of security because the access token never passes through the user's browser.

Implicit Grant

The Implicit Grant is used for single-page applications (SPAs) where storing client secrets securely is not possible. It directly provides an access token.

Steps

1. The user is redirected to the Authorization Server, logs in, and approves access.
2. Instead of returning an authorization code, the Authorization Server directly returns an access token in the URL.
3. The client application uses this token to access the Resource Server.

⚠️ Note: The Implicit Grant is now considered deprecated in OAuth 2.1 and modern applications should use the Authorization Code flow with PKCE instead.

Resource Owner Password Credentials Grant

Used when the application is trusted, and the user directly provides their credentials to the client application.

Steps

1. The user enters their credentials directly into the application.
2. The application sends these credentials to the Authorization Server.
3. If valid, the Authorization Server responds with an access token.
4. The application uses the access token to request data from the Resource Server.

This grant type should only be used when you have a high degree of trust in the client application, as it involves sharing the user's password with the client.

Client Credentials Grant

Used when a client application needs to access its own resources without user intervention.

Explanation

1. The application sends its client ID and secret to the Authorization Server.
2. If valid, the Authorization Server responds with an access token.
3. The application uses the token to access the Resource Server.

This is ideal for server-to-server communication where no user is involved in the authorization process.

Refresh Token Grant

Allows clients to obtain a new access token using a refresh token without requiring user intervention.

Steps

1. The client application initially receives both an access token and a refresh token after a successful authentication process using a grant type (e.g., Authorization Code grant).
2. The client uses the access token to request protected resources.
3. When the access token expires, the client sends the refresh token to the Authorization Server.
4. If the refresh token is valid, the Authorization Server returns a new access token (and optionally a new refresh token).
5. The client continues using the new access token to access resources.

This flow enables long-lived sessions without requiring the user to re-authenticate.

Device Authorization Grant

Used for devices with limited input capabilities, such as smart TVs and IoT devices.

Steps:

1. The user initiates the device authorization.
2. The device requests authorization from the Authorization Server.
3. The Authorization Server returns a device code and a user code.
4. The device displays the user code and verification URI.
5. The user navigates to the verification URI and enters the user code.
6. The Authorization Server prompts the user to authorize the device.
7. Once approved, the device polls the Authorization Server for the access token.
8. The Authorization Server issues an access token.

Conclusion

OAuth2 provides multiple grant types to support different application architectures. Choosing the correct flow depends on:

• Security requirements
• Client type (web, mobile, server-to-server)
• User interaction needs

In modern architectures the most commonly used flows are:

• Authorization Code + PKCE
• Client Credentials
• Refresh Token

Understanding these flows helps developers design secure authentication and authorization systems.

Note: The Mermaid code for the diagrams is included in this article, but Dev.to does not render the diagrams correctly. For readability, the diagrams are shown as images. If you want to view or reuse the original Mermaid source, you can find it in the repository: https://github.com/dkforge31/Understanding-OAuth2-Grant-Types