Authentication Flows

We know that OpenID Connect (OIDC) extends the OAuth 2.0 protocol by introducing new flows, reusing some of the existing ones, and by placing the user, not the application, at the center of such flows. In this chapter, we will go through OAuth 2.0 and OIDC basics, learn about their flows, similarities, and differences, and where they can be used and why.

The chapter covers the following main topics:

• The authorization code grant flow
• The authorization code grant flow with Proof Key for Code Exchange
• The implicit grant flow
• The client credentials grant flow
• The Resource Owner Password Credentials (ROPC) grant flow
• The On-Behalf-Of (OBO) flow
• Hybrid flows

Here’s a list of the flows and their support:

Figure 4.1 – OIDC/OAuth 2.0 flow support summary

The authorization code grant flow

The authorization code grant flow is used by a client application to obtain both an access token (or an ID token for OIDC) and a refresh token, and it is even more secure when used with confidential clients. Because this is a redirection-based flow, the client must be able to connect with the resource owner’s user agent (usually a web browser) and receive inbound requests from the authorization server (via redirection).

The flow is described in the following diagram:

Figure 4.2 – Authorization code grant flow

The diagram is explained in detail in the following list. Each item reports the specific interaction that occurs at the numbered point in the diagram:

1. The client application requests an authorization code (authorization grant proof) from the /authorize endpoint of the authorization (AuthZ) server. This is what a request looks like:

   GET /authorize?

   response_type=code

   &client_id=s6BhdRkqt3

   &redirect_uri...

The authorization code grant flow with PKCE

PKCE is a more secure variation of the authorization code grant flow that was mainly introduced for SPAs. It was introduced to mitigate the authorization code interception attack, which aims to steal the authorization code from a legitimate application in order to obtain an access token.

Let’s see how this flow works:

Figure 4.3 – PKCE

The flow is explained in detail as follows:

1. The client application requests an authorization code (authorization grant proof) from the /authorize endpoint of the authorization (AuthZ) server. Before sending the request, the client application generates a secret named code_verifier; it transforms it with a transformation named t_m and attaches the following to the authorization request:
   • t(code_verifier): The transformed secret
   • t_m: The transformation function
2. The authorization server stores the transformed secret, t(code_verifier), and the transformation function...

The implicit grant flow

The implicit grant flow is used to obtain an access token (or an ID token for OIDC) and is optimized for SPA public clients. Such clients typically run in a web browser, using a client-side scripting language such as JavaScript. This flow does not issue a refresh token, and the interaction between the client and the authorization server is done through the /authorize endpoint only.

The flow is described in the following diagram:

Figure 4.4 – Implicit grant flow

The diagram is explained in detail as follows:

1. An access token is requested by the client application; this is achieved by accessing the /authorize endpoint on the authorization (AuthZ) server. This is what a request looks like:

   GET /authorize?

   response_type=token    (or id_token)

   &client_id=s6BhdRkqt3

   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

   &scope=openid%20resource_server_id

   &nonce=n-0S6_WzA2Mj

   &state=af0ifjsldkj...

The client credentials grant flow

The client credentials grant is a flow that must be used only by confidential clients, and it enables non-interactive application authentication. This makes sense because embedding the application credentials in a public client (such as a mobile application) exposes them to malicious users, making the whole purpose of keeping such credentials safe and secure in vain.

The flow is described in the following diagram:

Figure 4.5 – Client credentials grant flow

The diagram is explained in detail as follows:

1. The client application requests an access token directly from the /token endpoint of the authorization (AuthZ) server by providing its previously configured credentials (such as client_id and a secret or certificate). This is what a request looks like:

   GET /token?

   grant_type=client_credentials

   &client_id=s6BhdRkqt3

   &scope=resource_server_id

   &client_secret=uayaskiR$£QDcfa

   Host: authzserver.example...

The ROPC grant flow

The ROPC flow moves the resource owner’s credential management into the client application. The resource owner is prompted directly by the client application, which usually has a form where the user can insert their credentials. For this reason, ROPC is not a recommended flow because it trusts that the client application will not misuse a user’s credentials.

The flow is described in the following diagram:

Figure 4.6 – ROPC grant flow

The diagram is explained in detail as follows:

1. The resource owner directly inserts their credentials within the client application.
2. The client application requests an access token directly to the /token endpoint of the authorization (AuthZ) server by sending the credentials the resource owner provided in the previous step. This is what a request looks like:

   POST /token?

   grant_type=PASSWORD

   &client_id=s6BhdRkqt3

   &scope=resource_server_id%20offline_access

   &username=userid1...

The OBO flow

The OBO flow (which is not part of standard OAuth 2.0 (IETF) but is specific to Microsoft Azure Active Directory implementation) is used to allow a resource server to call another resource server in the background without any user interaction. This is useful when there are two resource servers, usually managed by different parties, that trust the same authorization server and contribute to the logic of a single application, and need to be used in the background seamlessly. To allow a resource server to use the OBO flow, the authorization server must be properly configured.

Figure 4.7 – OBO flow

The diagram is explained in detail as follows:

1. The client application requests an access token to the authorization server using the authorization code grant flow or another authentication flow, as described in the previous paragraphs.
2. The authorization server validates the request and issues an access token to the client application.
...

Hybrid flows

Hybrid flows (part of the OIDC specification) mix authorization code grant and implicit flows together, enabling the issuing of access tokens and ID tokens at different phases compared to when those flows are used alone.

During the first call to the /authorize endpoint of the authorization server, a client application can specify the following values for the response_type parameter, making the authorization server behave differently:

• code token: When specified in the HTTP request, an access token and an authorization code must be included in a successful response
• code id_token: When specified in the HTTP request, an authorization code and an ID token must be included in a successful response
• id_token token: When specified in the HTTP request, an ID token and an access token must be included in a successful response
• code id_token token: When specified in the HTTP request, an access token and an ID token must be included in a successful response
...

Summary

In this chapter, we have gone through the authorization and authentication flows provided by OAuth 2.0 and OIDC protocols. We described their usage and their main objectives in terms of the best scenarios where they can be used.

In the next chapter, we will get a broader view of how these flows can be used to solve specific problems by providing a set of recipes, or patterns, that can be used in particular scenarios that are usually encountered when working in an enterprise.