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 take 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 us 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 more popular flows that are defined as part of OpenID Connect are
- Code (also known as Authorization code)
- Implicit
- 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 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 modern IAM solution, to not only enable use cases of today but also of the future.
Here in 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.