Single Sign-On (SSO)

Single Sign-On, usually shortened to SSO, means a user authenticates once with a trusted identity system and can then access multiple applications without typing credentials again for each one.

The important distinction is that SSO centralises authentication, not necessarily the whole application session. Each application may still keep its own local session, cookies, and permissions. What becomes shared is the proof that the user has already signed in with an identity provider.

In a typical web setup there are three actors:

• the user and their browser
• the identity provider or IdP, which handles login and issues assertions or tokens
• the service provider or relying party, which is the application the user wants to use

The flow usually works like this.

1. The user opens an application such as webmail.
2. The application sees no local session and redirects the browser to the IdP.
3. The IdP checks whether it already has a login session for that browser. If not, it asks for credentials and often a second factor.
4. After successful login, the IdP issues a signed assertion or token.
5. The browser returns to the application with that proof.
6. The application validates the signature, issuer, audience, expiry time, and sometimes a nonce.
7. The application creates its own local session and serves the protected page.

If the same user then visits another application that trusts the same IdP, steps 1 and 2 still happen, but step 3 is different. The IdP already has a session cookie, so it does not ask for credentials again. It issues a new assertion for the second application, and that application creates its own session. The user experiences one sign-in across several systems.

The common protocols are SAML and OpenID Connect. SAML is older and still common in enterprise environments. OpenID Connect is built on OAuth 2.0 and is common in modern web and mobile systems. The browser experience can look similar in both cases, but the token formats and integration style differ.

SSO brings clear operational benefits. It reduces password sprawl, makes multi-factor authentication easier to enforce in one place, and simplifies account disablement when someone leaves an organisation. It also improves auditability because login events pass through one control plane.

It also changes the failure model. The IdP becomes a high-value dependency. If it is unavailable, new logins across many systems may fail at once. A weak IdP session policy can widen the blast radius of a compromised browser session. Single logout is also harder than people expect. Removing the IdP session does not instantly destroy every application session unless each application participates correctly, which is one reason “log out everywhere” is often inconsistent.

There are other integration details that cause real trouble in production: clock skew can break token validation, bad attribute mapping can give the wrong roles, and over-broad trust between applications can expose more systems than intended.

SSO is therefore not just a login convenience feature. It is a trust architecture. Done well, it concentrates authentication controls in one place and reduces friction for users. Done badly, it creates one central point where outages, misconfiguration, or account compromise affect many services at the same time.