OAuth & OIDC Overview
OAuth and OIDC grant types, also called flows, refer to the methods of getting tokens to make requests to a resource server.
What Grant Types Are There
The most common OAuth and OIDC flows include:
The flows considered legacy are:
Implicit Flow - not recommended in any scenario. The authorization code flow with PKCE should be used instead.
Resource Owner Password Credentials Flow - should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application).
OAuth Flow Participants
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.
How to Pick Right OAuth & OIDC Flow for Application
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.
Flows Including Consent
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.
Implicit Flow - not recommended in any scenario. The authorization code flow with PKCE should be used instead.
Flows Without Consent
Client Credentials Flow - for machine-to-machine environments
Resource Owner Password Credentials Flow - should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application).
Tip
Almost all flows can have the consent step skipped for highly trusted and/or internal applications.
Redirect and Decoupled Flows
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.
Pick the Right Flow for Application
 |