Want to know how OIDC works? Read on and find it out.
This is a series of blogs exploring OAuth and OIDC:
OAuth 2.0 Explained in Simple Words - Part I: What and Why
OAuth 2.0 Explained in Simple Words - Part II: OAuth 2.0 Flows, Authorization Code Flow and Client Credentials Flow
OAuth 2.0 Explained in Simple Words - Part III: OAuth 2.0 Flows, PKCE Flow
OIDC Explained in Simple Words - Part I: OIDC as an OAuth 2.0 Enhancement
OIDC Explained in Simple Words - Part II: OIDC as an Modern SSO Standard
Note: Before jumping on OIDC, it's better to have some understanding on OAuth 2.0 . You can check out OAuth 2.0 Explained in Simple Words series, which is a fairly complete tutorial on OAuth 2.0.
This post continues from OIDC Explained in Simple Words - Part I. We will take a look at what SSO (Single Sign-On) is and its benefits, and then explore some modern integration patterns where OIDC is used as a SSO standard.
1. What SSO (Single Sign-On) is
SSO has been prevalent in organizations for years, but its importance is a lot of times overlooked. As the big trend is moving to cloud and taking advantage of third-party services, seamless and secure access to multiple applications is essential for maintaining operation efficiency and a smooth customer experience. This is done via SSO.
SSO itself is an authentication mechanism to allow users to securely access multiple applications using just one set of credentials. Furthermore, with SSO, a user doesn't need to sign on repeatedly to different applications, meaning the user needs to sign on just once and he will gain access to all authorized applications, websites and data from an organization or multiple related organizations.
2. Why SSO is Important
There are many benefits of using SSO, such as enhanced security, increased productivity, lowered IT costs and improved user experience.
Enhanced Security
Cybercriminals usually target usernames and passwords. In other words, the more accounts a user has, the more management overhead and vulnerabilities it has. Since users only need to remember one credential, they tend to use more complex and secure password.
A usual misconception about SSO is that if this only account is stolen, the whole system is compromised. While that seems true at first glanced, the reality is that with good practices, the probability of compromising that account is significantly lowered.
A great strategy is to use MFA (Multi-Factor Authentication) with SSO. MFA requires a user to present at least two different types of means to authenticate himself. For example, a username/password and a push notification to cell phone.
As a result, the security benefits of SSO far outweighs its issue.
Increased Productivity
SSO increases employee productivity by reducing the time they spend signing on and managing passwords. More often than not, an employee needs to interact with multiple applications in the day-to-day work. While he is spending time logging into different accounts, remembering them and retrieving them could be some other overheads, plus changing and resetting password.
The time and effort can be saved with one account.
Lowered IT Costs
Studies have shown that more than 50% of help desk calls are about password issues. In other words, the more passwords a user has, the more work IT help desk will have. Furthermore, if an organization has some specific password policy that requires long and complicated password, the burden could be increased more. SSO will help in reducing this kind of costs.
SSO Improves User Experience
With the move to cloud, employees are starting to use more apps in the work. A lot of accounts could be frustrating to deal with. Signing-in once not only increases productivity, it enhances employees' job satisfaction as well.
SSO also improves customer experience. Sometimes, a customer abandons his cart simply because of forgotten password or password reset issue. SSO alleviates this kind of issue and provides a seamless experience.
3. OIDC as a SSO Standard
There are two popular SSO standards that are popular for SSO: SAML and OIDC.
SSO doesn't have to be based on standards, but using standards has a lot of benefits and it becomes a general practice in industry to use SAML or OIDC for SSO.
We know that OAuth 2.0 by itself is more of privilege delegation protocol (see OAuth 2.0 Explained in Simple Words - Part I), and OIDC adds an identity layer on top of OAuth 2.0, which makes it very suitable for SSO. SAML is another popular SSO standard, especially in enterprise SSO. We will focus on OIDC in this post.
Modern SSO Integration Pattern with OIDC
Let's take a look at an example to understand how modern SSO works with OIDC.
In the below diagram
An OIDC provider acts as the core of the SSO system within an enterprise intranet
There are internal and external apps (Client) that are interacting with this system
API1 and API2 are API resources (Resource Server) that client application can access and they have their own databases
The external/internal application can be either a public client or a confidential client depending on the settings of the context
The OIDC provider is connected to an enterprise directory where the user accounts are stored
Users can be either within intranet or external facing
Authorization Code Flow
An example Authorization Code flow would be that a user starts to use Internal App1, the latter redirects the user to OIDC Provider for authentication. After user authenticates, OIDC provider returns Access Token and ID Token. Internal App1 extracts user information from the ID Token and processes some business logics. Then the Internal App1 sends a request with the Access Token to the API1. API1 verifies the Access Token and return the API resources to Internal App1. The app processes the resources and further assists user operations.
Client Credentials Flow
Another example with Client Credentials flow would be that API1 needs request some resources from API2. This would be a server-to-server (or machine-to-machine) call. API1 first gets an Access Token (No ID Token) from OIDC server and then sends the request along with the Access Token to API2. API2 verifies the Access Token and returns the resources.
Sessions and How SSO is Achieved
Usually the client applications manage user sessions by themselves, meaning each client application will maintain a user session for its own and separate client apps have separate user sessions. This is pure client application session and has nothing to do with the OIDC provider. The good thing for this kind of app session is that whenever the user comes back to the same client app where a user session exists, the user doesn't need to authenticate anymore.
However, if no session exists for the client application, it will redirect the user to the OIDC provider for authentication and once authenticated, the OIDC server will create a user session too. Besides that, the OIDC provider will return an ID Token to the client application. Then the client app extract user info from the ID Token so that it knows which user it is and hence create a client app session for that user.
Next, when the user tries to access another client app, where he is redirected to the OIDC provider again. But this time, since the user has already authenticated to the OIDC provider (in the last transaction) and a user session does exists, the user doesn't need to authenticate anymore. The Access Token and ID Token will be directly returned to the client app.
In all cases, as long as the apps are interacting with the same OIDC provider, only one account is needed and only one login is needed during a certain time. This is how SSO is achieved.
4. Sum Up
In this post, we took a brief look at what SSO (Single Sign-On) is and its importance. Next, we explore some integration patterns where OIDC is used as a standard for SSO. When user is involved in an OIDC flow, a user authenticated to the OIDC provider does NOT need to authenticate again and that's how SSO is achieved.