1. Introduction

In this tutorial, we’ll discuss the OAuth 2.0 protocol flow. We’ll discuss the basic protocol flow. There are other variations to this flow bases on the different use cases, for example in case of refresh tokens there is an extra step to get the new access token in case the existing access token is expired.

2. OAuth 2.0 flow

The following diagram shows the typical OAuth 2.0 protocol flow:

The diagram shows the interaction between four roles in OAuth protocol.

(A). The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner, or indirectly via the authorization server as intermediary.

(B). The client receives the authorization grant. Authorization grant is one of four grant types. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.

(C). The client presents the authorization grant to the authorization server and requests for access token.

(D). The authorization server issues an access token after authenticating client and validating authorization grant.

(E). The client presents the access token to the resource server and requests for the protected resource.

(F). The resource server validates the access token, and if valid, serves the request.

3. Terms related to OAuth 2.0

3.1 Authorization Grant

An authorization grant is authorization by the resource owner to access its protected resources. An authorization grant represents a credential and is used by client to obtain an access token. OAuth specification defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials. OAuth also provides mechanism for defining additional types. The most common OAuth grant types are:

• Authorization Code
• Client Credentials
• Device Code
• Refresh Token
• PKCE
• Implicit Flow (Legacy)
• Password Grant (Legacy)

3.2 Access Token

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. Tokens have scope information and duration of access. Access tokens do not have to be in any particular format. OAuth servers have defined their own different formats. Access tokens may be either “bearer tokens” or “sender-constrained” tokens. Sender-constrained tokens require the OAuth client to prove possession of a private key to use the access token. Following should be noted about access tokens:

• Access tokens are not meant for client so client should not read or interpret the access tokens.
• Access tokens do not reveal user indentity and information to the client.
• Access tokens should only be used to access protected resource from the resource server.

3.3 Refresh Token

Refresh tokens are credentials used to obtain access tokens. One use case of refresh token is when the current access token expires, refresh token can be used to obtain a new access token.

3.4 Scope

Scope in OAuth 2.0 defines the limit on access of an application to the user’s account. An application can request for scope(s), this information is presented to the user in the consent screen. The application is granted access to these scopes only. OAuth 2.0 specification does not specify values for scope as this can vary for every application.

4. Conclusion

In this tutorial, we discussed the OAuth 2.0 protocol flow. The understanding of the OAuth flow is very important to understand its implementation and various use cases.