OpenID Connect Flows

In today’s text, I will describe and explain OpenID Connect Flows. The processes of authentication are described in the OpenID Connect specification. As OpenID Connect is built upon OAuth, part of the concepts below will have the same meaning as in the case of OAuth. 

What Is an OpenID Connect Flow?

Flow is the OpenID Connect counterpart of the OAuth Grant Type. It is a process of obtaining an Access Token. It describes the exact sequence of steps involved in handling a particular request. As a result, flow affects how applications involved in handling particular requests communicate with one another.

Everything is more or less similar to Grant Types from OAuth. However, there is a slight difference in how the abstract protocol works in OpenID Connect.

1. The RP (Client) sends a request to the OpenID Provider (OP).

2. The OP authenticates the End-User and obtains authorization.

3. The OP responds with an ID Token and usually an Access Token.

4. The RP can send a request with the Access Token to the UserInfo Endpoint.

5. The UserInfo Endpoint returns Claims about the End-User.

As for abbreviations and concepts used in the above description:

• Claim is a piece of information about the requesting Entity.
• RP means Relying Party. It is an OAuth 2.0 Client requiring End-User Authentication and Claims from an OpenID Provider.
• OP means OpenID Provider. It is an OAuth 2.0 Authorization Server that is capable of Authenticating the End-User. Additionally, it provides Claims to a Relying Party about the Authentication event and the End-User.
• UserInfo Endpoint is a protected Resource. When presented with an Access Token by the Client, it returns authorized information about the End-User. The information is represented by the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use HTTPS and MAY contain a port, path, and query parameter components.

OpenID Connect Flows

Opposite to OAuth being the authorization protocol, OpenID Connect is the authentication protocol. It extensively relies on pseudo-authentication, a mechanism of authentication available in OAuth. In the current OpenID Connect specification, we can find three grant types:

1. Authorization Code Flow
2. Implicit Flow
3. Hybrid Flow

The value of the response_type parameter from the Authorization Request determines the Flow for the current process. The table below illustrates how particular values map to Flows.

The biggest difference between the flows comes in the form of the “place” where we get our Access Tokens. In the case of Authorization Code, we get them from Token Endpoint. In Implicit Flow, we get Access Tokens from Authentication Response. While in Hybrid Flow, we can choose the source of our tokens.

Below you can find a table from the OpenID specification. It can be very useful while picking the Flow you want to use. The Property column contains a set of features. At the same time, the rest of the columns specify if a particular Flow supports the feature or not.

Additionally, unlike OAuth, there were no major changes here. Therefore, no Flows were deprecated, and all three are still recommended.

Flows Lexicon

Authorization Code Flow

This flow works by exchanging Authorization Code directly for an ID Token and an Access Token. Authorization Code can be obtained from Token Endpoint. Because we exchange data directly, we can not expose any details to malicious applications with possible access to the User Agent.

Furthermore, authentication itself can be done before exchanging code for a token. Therefore, this flow is best suited for Clients that can securely maintain a Client Secret between themselves and the Authorization Server. All tokens are returned from Token Endpoint when using the Authorization Code Flow.

Implicit Flow

Opposite to the Authorization Code flow here, we get our tokens from Authorization Endpoint. Here Access and Id Tokens are returned directly to the client, exposing them to any application with access to the end user’s Agent.

Thanks to this direct return, this flow is best suited for Clients implemented in a browser. Moreover, the Authorization Server does not perform Client Authentication, and Token Endpoint is not used.

Hybrid Flow

It is the most complex of all three flows. Here, the access token can be returned from both Authorization and Token Endpoints. It can also be returned from both of them at the same time. What is pretty interesting is that the returned tokens are not guaranteed to be the same.

Because this flow combines the two previously mentioned, both Authorization and Token endpoints inherit some part of their original behavior. There are also differences here, mostly in the process of handling and validating ID Token.

Summary

OpenID Connect specification describes fewer procedures than OAuth. However, it is more in detail about how flows should work. So I hope that this humble lexicon of OIDC Flows will come in handy to you at some point. Thank you for your time.