OpenID Connect Flows

OpenID Connect defines three flows, two of which build upon flows defined in OAuth 2.0. These flows dictate what response types an authorization request can request and how tokens are returned to the client application.

This article describes each flow, when to use it, and how to secure it.

Authorization Code Flow

The authorization code flow allows you to request an authorization code from the authorization endpoint, which you can then exchange at the token endpoint for an identity token and, optionally, an OAuth access token. This flow was initially created for server-side applications.

This flow does not expose any tokens to the front-channel, as only the authorization code is returned in the authorization response.

To ensure only an authorized client application can swap codes for tokens, use client authentication when using a confidential client (a client application that can keep a secret).

To prevent authorization code injection, use Proof-Key for Code Exchange (PKCE).

This flow allows you to continue to act on the user’s behalf, when they are no longer present, by using a refresh token authorized for offline access. Ideally, offline access refresh tokens are only used with confidential clients.

Implicit Flow

The implicit flow allows you to request an identity token and, optionally, an OAuth access token, directly from the authorization endpoint. This flow was initially created for browser-based applications.

This flow exposes tokens to the front-channel. Tokens will always be visible to the browser and, therefore, code running within the browser. However, this can be acceptable when only dealing with identity tokens, assuming you are using nonce validation, and the identity token is not stuffed with PII.

This flow is generally regarded as deprecated in the OAuth community; however, using OpenID Connect nonce and access token hash (at_hash) validation significantly improves its security profile compared to pure OAuth.

Now that we have CORS and PKCE, I recommend following the OAuth for browser-based apps BCP and avoiding this flow in favor of the authorization code flow with PKCE.

Hybrid Flow

The hybrid flow allows authorization codes and tokens to be returned from the authorization endpoint at the same time. This flow can be useful if the client needs to perform some processing before swapping an authorization code for tokens.

This flow exposes tokens to the front-channel, in the same way as the implicit flow. However, this can be acceptable when only dealing with identity tokens, assuming you are using nonce validation, and the identity token is not stuffed with PII.

Requesting an authorization code and an identity token from the authorization endpoint at the same time can even be advantageous for the client application. Performing nonce validation early can be beneficial, and checking the code hash (c_hash) allows the client application to detect authorization code injection.

To have the authorization server also detect authorization code injection, use Proof-Key for Code Exchange (PKCE).

This flow also allows you to continue to act on the user’s behalf, when they are no longer present, by using a refresh token authorized for offline access. Ideally, offline access refresh tokens are only used with confidential clients.

Which Flow Should I Use?

The general advice is to use the authorization code flow with PKCE for all types of applications. This flow requires the least amount of effort for the client application to implement while giving the best level of security. This is the recommendation that is being proposed for OAuth 2.1.

If the client application cannot support PKCE, I recommend falling back to using the hybrid flow response type of “code id_token” with nonce and c_hash validation.

Flow Features

	Authorization Code	Implicit	Hybrid
All tokens returned from authorization endpoint
All tokens returned from token endpoint
Tokens sent via user agent
Client can be authenticated (e.g. using client secret)
Can use refresh tokens
Communication in one round trip
Most communication server-to-server

Response Types by Flow

Flow	Response Types
Authorization Code	`code`
Implicit	`id_token`
Implicit	`id_token token`
Hybrid	`code id_token`
Hybrid	`code token`
Hybrid	`code id_token token`

Tables adapted from OpenID Connect 1.0 Core Specification.