24.1 Building Blocks of OAuth 2.0

The following are the building blocks of OAuth 2.0.

24.1.1 OAuth 2.0 Roles

OAuth 2.0 consists of the following four roles:

  • Resource Owner: Entity that grants access to a protected resource. It can be a system or a person (end-user) owning the resources.

  • Resource Server: Server that hosts the protected resources. It accepts and responds to the protected resource requests using the access tokens.

  • Client: Application that requests and get authorization on behalf of the resource owner to access a protected resource.

  • Authorization Server: Server that issues access tokens to the client after the successful authentication of the resource owner and obtaining authorization.

24.1.2 OAuth 2.0 Grants

By default, Advanced Authentication supports the following OAuth 2.0 grant types. However, if you require to use the Resource owner password credential grant, you have to enable it using Advanced Authentication settings. For more information on OAuth 2.0 grant types, see the link.

Authorization Code

In authorization code, an authorization server acts as an intermediary between the client and the resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server, which in turn directs the resource owner back to the client with the authorization code.

The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API.

The following diagram describes the workflow of authorization code grant.

The workflow for authorization code includes the following steps:

  1. The OAuth client initiates the flow when it directs the user agent of the resource owner to the authorization endpoint. The OAuth client includes its client identifier, requested scope, local state, and a redirection URI.

  2. The authorization server authenticates the resource owner through the user agent and recognizes whether the resource owner grants or denies the access request.

  3. If the resource owner grants access, the OAuth client uses the redirection URI provided earlier to redirect the user agent back to the OAuth client. The redirection URI includes an authorization code and any local state previously provided by the OAuth client.

  4. The OAuth client requests an access token from the authorization server through the token endpoint. The OAuth client authenticates with its client credentials and includes the authorization code received in the previous step. The OAuth client also includes the redirection URI used to obtain the authorization code for verification.

  5. The authorization server validates the client credentials and the authorization code. The server also ensures that the redirection URI received matches the URI used to redirect the client in Step 3. If valid, the authorization server responds back with an access token.

Implicit Grant

The implicit grant is similar to the authorization code grant with two distinct differences.

  • It is used for user-agent-based clients. For example, single page web apps that cannot keep a client secret because all the application code and storage is easily accessible.

  • Secondly, instead of the authorization server returning an authorization code which is exchanged for an access token, the authorization server returns an access token.

The following diagram describes the workflow of Impicit grant.

The workflow for implicit grant includes the following steps:

  1. The OAuth client initiates the flow by directing the user agent of the resource owner to the authorization endpoint. The OAuth client includes its client identifier, requested scope, local state, and a redirection URI. The authorization server sends the user agent back to the redirection URI after access is granted or denied.

  2. The authorization server authenticates the resource owner through the user agent and verifies whether the resource owner grants or denies the access request.

  3. If the resource owner grants access, the authorization server redirects the user agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment.

  4. The user agent follows the redirection instructions by making a request to the web server without the fragment. The user agent retains the fragment information locally.

  5. The web server returns a web page, which is typically an HTML document with an embedded script. The web page accesses the full redirection URI including the fragment retained by the user agent. It can also extract the access token and other parameters contained in the fragment.

  6. The user agent runs the script provided by the web server locally, which extracts the access token and passes it to the client.