OAuth 2.0 grant types explained (2024)

Authorization determines what types of files and resources specific users can access. It’s an essential part of building secure platforms and apps, responsible for giving the right people access to the right files.

But how does authorization work in the back end? That’s where the frameworks (like OAuth 2.0) come in. This approach delegates user authentication to the service that handles a user’s account and allows third-party apps to access that account in a secure way.

In order to select the right OAuth grant type, you need to define your goals, understand the different grant types available, and what benefits they can offer to your app or platform.

OAuth 2.0 (a.k.a Open Authorization) is the industry standard protocol for authorization. It offers client/developer simplicity and has been designed as a means of granting access to a set of resources, while providing specific authorization flows for a range of different apps, on behalf of the user.

OAuth 2.0 provides consented access while also acting as a way to restrict actions, dictating what the client can and can’t perform. It is an authorization protocol, not an authentication protocol.

These roles define the essential components of an OAuth 2.0 system and are a part of the core specifications of the OAuth 2.0 framework:

• OAuth owner: The user/system that owns the protected resources and can grant access to them.
• Client: The client is the system/person who requires access and must hold the appropriate access token.
• Authorization server: The server that receives requests from the client for access tokens. The authorization server exposes two endpoints, the authorization endpoint and the token endpoint.
• Resource Server: This server protects the users’ resources and receives access requests from the client. The server accepts and validates access tokens and will, in turn, give access to the appropriate resources.

Plus, scopes play important roles in the OAuth 2.0 concept. They’re used to specify the exact reason for access to be granted. Scope values and the resources they relate to are dependent on the resource server.

Even before OAuth 2.0 can be used, the client must acquire their own set of unique credentials from the authorization server. This will then allow the client to identify and authenticate themselves when requesting an Access Token.

Access requests using OAuth 2.0 are initiated by the client (such as an app or website). The request, exchange, and response all follow the same general flow:

1. The client requests authorization, which could be from the server. The server will then supply the client ID and secret to prove identity. It also provides the scopes and the endpoint to send the access token and authorization code to.
2. The authorization server authenticates the client and verifies the request scopes are permitted.
3. The resource owner will interact with the organization server to grant access.
4. The authorization server redirects back to the client with the code/access token depending on the grant type.
5. With the access token, the client will gain access to the resources, from the resource server.

A grant is a method of acquiring an access token. This means OAuth 2.0 grants are a set of steps that the client will have to go through to get resource access authorization. The authorization framework will provide several different grant types to address different scenarios.

In short, there’s an OAuth grant flow and type to suit most use cases.

Authorization Code Grant is the most widely used grant type to authorize the client.

In this scenario, the authorization server will return a single-use authorization code to the client, which is then exchanged for an access token.

This is the best option for traditional web-based apps, where the exchange can happen securely on the server side. The client’s secret cannot be stored securely so authentication during the exchange is limited to the use of the client ID alone.

PKCE is a security-centric OAuth grant type. The main concept behind this grant type is proof of possession. This essentially means the client app needs to prove to the authorization server that the authorization code is authentic before being issued an access token. The PKCE flow includes a code verification measure and code challenge.

Interestingly, PKCE can be traced by the older grant type, the Implicit Grant Type. With no authorization code, the client app would receive the access token instantly after getting the end user’s consent. Since this flow took place entirely through browser redirect, it proved very risky and was not secure enough. From there, PKCE was born.

The device code grant type is used by browserless or input-constrained devices, used in the device flow to exchange a previous device code for an access token.

This grant flow usually goes like this:

• A client authorization server receives an access request from the kitchen (usually including its client identifier)
• End-user and device codes are created and shared by the authorization server, and the end-user receives a verification URI
• The end-user needs to utilize a user agent by the client, and then enter the end-user code to review this request
• The end-user is authenticated by the authorization server through this user agent, prompted to enter the user code
• The authorization server checks this code and asks the user to accept or decline the request
• The authorization server is asked by the client to verify if authorization is complete
• Once the server has validated the device code received by the client, access is granted and an Access Token is issued

This type of grant is used specifically by clients for non-interactive applications. For example, automated processes. In this case, the application would be authenticated by using the client ID and secret.

This is a type of grant flow that involves the exchange of a refresh token for a new access token. This allows clients to have a valid access token without having to interact with the user.

After the client sends a POST request to the authorization server a JSON object is provided. It’s also important to remember that Refresh Tokens operate differently from Access Tokens, meaning they are never sent to resource servers and only interact with authorization servers.

The first step to implementing the OAuth framework is to select the right authorization grant type to suit your case. This usually depends on your application type, but other factors weigh in too, such as the level of trust between your clients or the kind of experience you want users to have.

Here are some things to consider to help you select the right OAuth grant type::

• First-party or third-party client: A first-party client is one you trust enough to handle the end-users authorization credentials. A third-party client is one that you don’t trust.
• Access token owner: If you’re authorizing a machine to access resources and you won’t require the permission of a user to access the resources, you should implement the client credentials grant.
• Client type: Depending on whether or not the client is capable of keeping a secret will depend on which grant is most suitable for the client. For example, if the client is a web app that has a server-side component you should implement the authorization code grant.

With a solid foundation and a good understanding of different OAuth 2.0 grant types, you should have a clear idea of what is most suitable for you and your business. Picking the right grant type will help you keep your app secure when delivering a smooth user experience, too.

See how Kinde compares to other authentication providers.