Authorization Basics

4 mins read

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).

Explore OAuth & OIDC Flows

Cloudentity comes with multi-tenant authorization server as a service that supports all of the above OAuth & OIDC flows for getting security tokens.

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.

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.

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

Grant type selection diagram

Try it now

Cloudentity comes with multi-tenant authorization server as a service that supports all of the above OAuth flows for getting security tokens.

Updated: Sep 8, 2023