In today’s text I will describe and explain OpenID Connect Flows. The processes of authentication described in OpenID Connect specification.
As OpenID Connect is built upon OAuth part of the concepts below will have the same meaning as in case of OAuth. If you want to start your journey by reading about OAuth then here you can learn more.
What is an OpenID Connect Flow?
Flow is OpenID Connect counterpart of 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. 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.
From https://openid.net
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 concept used in 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 the HTTPS and MAY contain 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 3 grant types:
- Authorization Code Flow
- Implicit Flow
- Hybrid Flow
The Flow for the current process is determined by the value of response_type parameter from Authorization Request. Table below illustrates how particular values map to Flows.
From https://openid.net
The biggest difference between the flows comes in the form of “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. While the rest of the columns specifics if particular Flow supports the feature or not.
Additionally, unlike OAuth, there were no major changes here. No Flows were deprecated and all 3 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. This flow is best suited for Clients that can securely maintain a Client Secret between themselves and the Authorization Server. When using the Authorization Code Flow, all tokens are returned from Token Endpoint.
Implicit Flow
Opposite to 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. What is more, 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, 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 is the combination of 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 less procedures then OAuth. However, it is more on detail with how flows should work. I hope that this humble lexicon of OIDC Flows will come in handy to you at some point.
Thank you for your time.
Comments are closed.