OpenID Connect Flow: Have You Made the Right Choice of Flow For Your Application?

As more and more digital business initiatives emerge, which require applications and data to be accessed by those outside the corporate perimeter, the adoption of federation technologies has risen dramatically.

Among these technologies, OpenID Connect is starting to gain more relevance as a modern framework of flows, which enables clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users.

If you are not familiar with OpenID Connect, it is an identity standard built on top of OAuth 2.0 protocol. It allows applications to verify the identity of the end-user based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the end-user in a secure way.

Although OpenID Connect standard was initially used for internet authentication use cases for consumer facing applications, it has become very relevant for enterprise use cases also e.g. allowing identity assertion to compliant applications.

In other words, OpenID Connect standard is all about a set of defined process flows for “federated authentication,” built on OAuth 2.0 flows as the base. 

In this blog, let’s look at what flows you should consider for your application, because the type of OpenID Connect flow you chose is different with the type of client you’re using.

The 3 most popular flows that are defined as part of OpenID Connect are:

  1. Code (also known as Authorization code)
  2. Implicit
  3. Hybrid

If you are developing a web application that consists of a dedicated server side component which is capable of keeping the client secrets confidential, then the choice of flow is “Authorization Code” Flow (with confidential client). 

If you are developing a user agent based application, where the application is downloaded from a web server and executes within a browser on the device used by the resource owner, then this is a case of a public client as it is not considered capable of keeping a client secret confidential. In this case, the industry is seeing a rise in the use of “Authorization Code” flow with a public client and PKCE, which stands for Proof Key for Code Exchange vs “Implicit flow”, which was traditionally recommended. There are a couple of reasons for that. One is that more often than not, the design choice leans towards generating short-lived access tokens, which in turn necessitates the need for a refresh token, the provision for which is not available in the Implicit flow. And the other reason is that the Implicit flow is vulnerable to access token leakage as the user agent can see the access token and that can lead to exfiltration by malicious applications.

“Authorization Code” flow with a public client and PKCE is also recommended for Single Page Apps (SPA) and native applications (desktop and mobile) due to the same reasons as above.

Hybrid flow is not often used in the industry. Even the use of “Implicit flow” has diminished recently.

A few years ago, Implicit flow’s usage was recommended for native mobile apps for achieving mobile SSO. However, given the mobile OS improvements about 3 years ago, Authorization code flow with a public client and PKCE has become more relevant for these use cases as well.  Authorization code flow (with a public client and PKCE) has now become the norm for OIDC implementations on mobile devices, as it is very secure compared to “Implicit Flow” and also supports refresh tokens.

As I mentioned previously, this is the same case for SPAs, “Implicit flow” in some cases continues to be used by developers for SPAs. But a better way to handle authentication for SPAs in a secure way is using “Authorization code” flow (with a public client and PKCE).

One additional thing to note is that, in Layer7 SiteMinder, we have even introduced (Cross-Origin Request Sharing) CORS support for the OIDC endpoints, which provides an additional layer of security to prevent malicious application loaded from an unregistered origin, to be able to obtain a set of tokens. The CORS support for the token endpoint is necessary to implement SSO in SPAs using “Authorization code” flow (with a public client).

In summary, given that most of the applications fall into either of these categories i.e SPA apps (Javascript/User-Agent-based), Web applications, or Native apps (mobile/desktop), we see that “Authorization Code” flow fits well broadly across these. There may be very few scenarios, where Implicit flow might still seem like a better choice – like if the user’s session timeout is short and there is no need for refresh token AND that the application is low risk and a single call to IDP is preferred, due to client limitations or desire for a fewer redirects and resultant latency.

Access Management is an evolving space and it is very important to invest in a modern IAM solution, to not only enable use cases today, but also for the future.

Here at Broadcom, we constantly strive for implementing modern standards within our products, to allow our customers the greatest breadth and flexibility to meet their access management and security needs.

About the author

Madhusudhan Yoganath is currently a member of the product management group at Broadcom, responsible for the strategy and direction of the Identity & Access Management product portfolio. He has close to 17 years of software industry experience, spanning various roles and verticals. He has spent the last 6 years in product management, in the field of Cyber Security and IAM, and was responsible for defining products for the Fortune 1000 customer base. Prior to joining CA technologies, Madhusudhan was a member of the product management team at Security Technology and Response Group at Symantec. He has more than a decade of experience in the field of Cyber Security across Product Management, Pre-Sales and Post-Sales Consulting engagements and focuses on building winning relationships.  Madhusudhan, while originally from Bangalore, is currently based out of Hyderabad’s Broadcom office.