[Tech] How Single Sign-On (SSO) works

Background

In the early days of Internet, many websites have manage the identities of their registered members themselves. There was no single standard but somehow, people keep track of the usual fields like First Name, Last Name, Email Address, Mobile Phone, Password, etc.

Then, came the concept of Identity Providers and Identity and Access Management (IAM). The earliest concept probably come from Microsoft Active Directory. The idea is that a centralized system will store and manage all the users' information and ensure their legitimacy. If users wish to access a service, they will authenticate with the centralized system and the system will provide the relevant access to the service for the service to process and allow the user into the service. Thus, the idea of Single Sign-On (SSO) was born!

These days, there are many identity providers catering to many groups of users. There are the public social networks, e.g. Meta (Facebook), Google (Gmail) etc. that provides SSO integration for their members to 3rd party services. Then there's corporate providers like Microsoft Azure IAM, AWS IAM, Okta which cater to enterprise / cloud services. Finally, there's the "newer" zero-trust platforms like Zscaler which provides a security layer to the different identity providers.

Anatomy

Don't worry if you haven't follow or understand anything thus far. The concept of Single-Sign On is quite simple actually. There are usually 4 parts that made up the most basic idea of SSO:

1. The User (Resource Owner) - This is you. You are trying to access something. Usually, you are a browser on the laptop or phone but sometimes you might even be hidden as a cache somewhere.
2. The Identity Provider - The system which manages the user's information, authenticity and authorization levels. You can think of it as the security guard who have access to all the staff working in the building.
3. The Service (Resource) Provider - The system which service you are trying to access. Think of it as the company / department that you are trying to access within the building.
4. The framework / process - This is the industry agreed-upon process by which everyone follows in order to gain access to the service. In a physical environment, this process can be imagined as you having to tap your staff pass on the gate, the gate verifies and open the gantry if you are who you are, and then the lift brings you to the right floor / department that you want to access. The whole process can be thought of as a framework.

Not so difficult after all right...?

OAuth 2.0 Authorization Framework

This is the industry standard for performing SSO and then granting user access to the relevant service. Using one of the workflow, Authorization Code Flow, which is also described in OAuth 2.0 RFC 6749 document, here's a quick explanation of the process.

Image from Digital Ocean

1. User (through the browser a.k.a user-agent) navigates to the service provider and wants to login.
2. Service (Resource) provider will redirect the user to login at the Identity Provider.
3. Identity Provider verifies the user and returns a set of information (e.g. scope of access, user details, time of access, validity) back to the Service provider. In technical jargon, this is also called the access token. In the payload, there may sometimes be an additional set of information which service provider can use to exchange for a "new" set of the information. This is called the refresh token.

The "golden" standard for security sake, is that the access token should be short-lived (minutes) while refresh token should be long-lived (valid for a few days to weeks). This is to prevent bad actors from stealing the access tokens and act as the legitimate user to access the service. Do note that some services creates their own session upon verification of the user and that session is independent of the access token. This means that the access token may expire but the session is still alive. Another good practice is to define the scope of usage that this access token is going to be used for. E.g. a user may be granted a read access + limited write access to perform some day to day task for a PMO-based service. However, if he wants to change critical information (e.g. his profile details or even crucial information), the service provider can prompt the user to sign in again at the Identity Provider, this time requesting for higher access. Identity provider can then utilize additional authentication methods like 2FA to verify the user on a deeper level.

SAML 2.0

In the enterprise world, many companies / service providers still uses SAML (Security Assertion Markup Language) 2.0 which is an XML based language to describe the "access token" payload and the exchange of information during the single sign-on process.

OpenID Connect

With the rise of Node.js, API-type services, and JSON, there is currently another newer industry standard called OpenID Connect (OIDC) which, in addition to having the access token during the authentication process, also require an ID token that is based on JSON Web Token standards (JWT). Such tokens uses JSON which is natively readable by JavaScript. In OIDC, the ID token represents the identity of the user (i.e. your passport) while the access token provides the scope of where you can go (i.e. your Visa / access documents). This allows OIDC-enabled service providers to provide even more useful functionalities like accessing APIs, GraphQL and others to give the user a personalized experience.

Service apps can also remove the need of sessions by using the identity token JWTs as their single source of truth, thus providing session-less experience. Without the need for sessions, service apps can utilize SPA, web workers & serverless APIs approach to provide feature rich websites to their users at much lower costs.