OAuth Grant Types

OAuth grants, also called OAuth flows, refer to the methods of getting tokens to make requests to a resource server.

Depending on the required security level, client application type and capabilities, backend part, and other conditions addressed as various use cases, there are different grant types to select. Every grant type features individual parameters that must be passed in an API request. Some flows require preparation when registering an application.

This article explains the OAuth grant types at a high level. It also includes a diagram to help consider the suitable grant type per a use case.

The typical mechanism of the grant flow involves four standard actors:

• Resource owner, typically, an end-user

• Client application

• Authorization server

• Resource server

The main idea is to allow the application to get the designated data securely. For this, the application gets authorization and then authenticates with the authorization server. Upon success, the application receives a token to access the protected resource with.

Note

It’s considered a good practice to limit the scopes the client application can request. It is done by providing the scopes to be requested as the value of the scope parameter. Then, the client application requests only the scopes that it needs. When no scopes are provided with the scope parameter, the client application receives access to all scopes.

The majority of flows cover the step of obtaining consent from the user (resource owner). For example, this consent can include the activity the application can perform on behalf of the user. The user must provide their consent explicitly, so they know what exactly the application can access. The user can cancel their consent at any time.

OAuth supports two authentication flow groups: redirect-based and decoupled.

For redirect-based flows, the resource owner gets redirected for authorization, authentication, and consent provision purposes. These flows assume that the resource owner accesses the client application and authorization server using the same device.

In decoupled flows, authorization, authentication, and consent provision are performed on a secondary device. This flow applies when a client cannot interact with the resource owner’s user agent. The scenarios for decoupled flows can be as follows:

• The resource owner approves a different person’s access request (for example, an operator). The approval is performed on the resource owner’s device apart from the operator’s one.

• The resource owner allows access to their resources for a browserless device, for example, a smart TV, wearable device, or POS terminal.

For the redirect-based grant types, it’s recommended to configure a redirection endpoint when registering the client application. With it, upon authorization, the resource owner is redirected to the redirection endpoint. When no redirect URI is configured for the application while it is required, it’s possible to provide the redirection right in the API request, specifying the redirect_uri parameter to the authorize endpoint. Also, this parameter is mandatory when the application features several redirect URIs configured.

The diagram below illustrates grant types selection per use case.

This section articles describe above-mentioned grant types in detail.

You can launch a free tenant with Cloudentity and explore grant types using Demo Application or Cloudentity APIs.

try now