Exploring OAuth 2.0 : A Comprehensive Look at Authorization Grants

In the previous two blogs, we explored the key OAuth roles and walked through the OAuth flow in action. In this blog, we’re diving deeper into one critical component of the OAuth process: the Authorization Grant.

An Authorization Grant is a credential that represents the resource owner’s permission for a client (application) to access protected resources. This grant is used by the client to request an access token from the authorization server, which then allows it to interact with the resource server on behalf of the resource owner.

OAuth 2.0 defines four core grant types that serve as the mechanism for obtaining access tokens:

1. Authorization Code Grant
2. Implicit Grant
3. Resource Owner Password Credentials Grant
4. Client Credentials Grant

These grants are designed to handle different scenarios and security requirements, ensuring that access to resources is granted securely and efficiently.

1. Authorization Code Grant

In the Authorization Code Grant flow, the client does not request access directly from the resource owner. Instead, it relies on an authorization server to act as an intermediary between the client and the resource owner. Here’s how it works:

1. The client first directs the resource owner to the authorization server (using the resource owner’s web browser or app).
2. At the authorization server, the resource owner can securely log in and grant permission to the client to access specific resources.
3. After the resource owner approves the request, the authorization server then redirects the resource owner back to the client, this time providing an authorization code.

This setup is secure because the resource owner’s credentials are only shared with the authorization server, never with the client. The authorization code is a temporary credential that the client can use to request an access token without ever needing to see the user’s password or sensitive login details.

2. Implicit Grant

Unlike the Authorization Code Grant, the Implicit Grant bypasses an intermediate step: instead of receiving an authorization code first and exchanging it for an access token, the access token is delivered directly after authorization.

Following is a Step-by-Step Walkthrough of implicit grant with a Spotify Example

Step 01: Client Requests Authorization from the Authorization Server

The client (in this case, our Spotify app) requests authorization by redirecting the user to the authorization server with a URL that looks something like this

This URL has parameters like:

• client id: The unique ID of our app
• response type=token: This tells the server we want an access token directly (not an authorization code).
• redirect uri: The URL where the server will redirect the user after authorization.
• scope: The permissions requested by the client (in this case, to read the user’s library).

url

Step 2: User Authenticates and Grants Consent

Once the user is redirected, they see a consent page from the authorization server. Here, they log in (if they aren’t already) and approve the app’s requested permissions. The authorization server then prepares to issue an access token directly to the client’s redirect URI.

Step 3: Access Token Delivered in Redirect URL

After the user grants consent, they’re redirected to the redirect_uri specified in Step 1, with the access token attached as part of the URL fragment:

Access Token

Step 4: Accessing Protected Resources The client uses the access token obtained in Step 3 to request data from the resource server. In our Spotify example, the client would send the access token in API requests to read the user’s library.

Security Considerations

Although the Implicit Grant was designed for simplicity, it’s become less favored in modern applications for a few reasons:

• Token Exposure in URLs: Since the token appears in the URL, it can be logged in browser history or accessed by other scripts running on the page.
• Lack of Client Authentication: The client isn’t authenticated in this flow, meaning there’s no mechanism to confirm the client’s identity beyond its redirect URI.

3. Resource Owner Password Grant

The Resource Owner Password Credentials (ROPC) Grant allows an application to use the resource owner’s (end-user’s) username and password directly to obtain an access token. This grant type is unique because, instead of redirecting the user to an authorization server, the application handles the user’s credentials itself.

However, this grant type comes with important considerations and should only be used in scenarios where:

• There’s a high level of trust between the resource owner and the client. For example, this might apply when the client is part of the device’s operating system or is a highly privileged application.
• Other, more secure grant types (such as the Authorization Code Grant) aren’t feasible.

Why Use This Grant Type?

While it may seem convenient to use the user’s username and password directly, the ROPC Grant is intended only for special cases. Here’s why:

1. Credentials Used Once: The user’s credentials are used for a single request to obtain an access token. After this, they’re not required again, as the access token (or a refresh token) can be used for further requests.
2. Limited Storage of Credentials: By exchanging the credentials for a long-lived access token or refresh token, applications can avoid storing the resource owner’s password for ongoing access.

While the Resource Owner Password Grant may offer efficiency, it’s less secure than other flows due to the need for the client to handle the resource owner’s raw credentials. Therefore, it’s reserved for cases with a high trust level or where other grant types are unavailable.

4. Client Credentials Grant

The Client Credentials Grant is used when an application needs to access its own resources, rather than acting on behalf of a user. This grant type is typically applied when:

1. The client (application) itself owns the protected resources it wants to access.
2. The client needs access to specific resources based on a pre-existing arrangement with the authorization server.

In this flow, the client uses its own credentials (like a client ID and secret) as an authorization grant to obtain an access token. This token allows it to interact with the resource server for certain tasks or data retrieval, but within the restricted scope agreed upon with the authorization server.

Here’s a breakdown of inputs and outputs for each OAuth 2.0 grant type

Here’s a comparative table highlighting the differences between the OAuth 2.0 authorization grant types, including their advantages and disadvantages:

In this blog, we’ve covered the different types of Authorization Grants used in the OAuth 2.0 framework. Each grant serves a unique purpose in how a client can securely obtain an access token.

In the next blog, we’ll take a closer look at the differences between these grants, along with their respective inputs and outputs. This will help you better understand when and why to use each grant type in your OAuth implementation. Stay tuned!