SSO (single sign-on) is an authentication arrangement in which a user proves their identity once to a central identity provider and then gains access to many separate applications without entering credentials again. In identity and access management within cybersecurity, SSO moves the login decision out of each application and into one trusted authority that issues signed assertions or tokens the applications accept.
The idea is simple, but the security consequences are large. SSO reduces password sprawl, makes central enforcement of MFA practical and allows an administrator to revoke access in one place. It also creates a single point of compromise: whoever controls the identity provider session, or the provider itself, controls access to everything connected to it.
How SSO works between the identity provider and applications
SSO works by separating the identity provider (IdP), which authenticates users, from the service providers or relying parties, which only consume the result. When a user opens an application, the application redirects the browser to the IdP. If the user already holds a valid IdP session, the IdP immediately returns a signed assertion or token describing who the user is; if not, it first runs the login, including any second factor.
The application never sees the password. It validates the signature with the IdP’s public key, checks the audience, issuer, expiry and nonce or request ID, and then creates its own local session. This produces two layers of sessions: the long-lived IdP session that makes the experience seamless, and short-lived application sessions that each relying party manages itself.
The following steps describe a typical browser-based flow with redirects:
- The user requests a protected page in the application.
- The application redirects the browser to the IdP with an authentication request.
- The IdP authenticates the user or reuses the existing IdP session.
- The IdP sends a signed assertion, or an authorization code exchanged for tokens, back to the application.
- The application validates the response and opens its own session.
SSO protocols and their typical use
SSO is not a protocol in itself but an outcome that several federation protocols deliver. The choice depends on the age of the application, the client type and the ecosystem. Modern web and mobile applications favor OpenID Connect, while many enterprise and software-as-a-service products still rely on SAML 2.0.
| Protocol | Token format | Typical environment | Notes |
|---|---|---|---|
| SAML 2.0 | Signed XML assertion | Enterprise web and SaaS | Mature, verbose, browser-centric |
| OpenID Connect | Signed JWT ID token | Web, mobile, APIs | Identity layer on top of OAuth 2.0 |
| Kerberos | Ticket from a key distribution center | Windows domains, internal networks | Integrated Windows authentication |
| WS-Federation | Signed XML token | Older Microsoft ecosystems | Largely replaced by SAML and OIDC |
| CAS | Service ticket | Universities, legacy portals | Simple ticket validation model |
OAuth 2.0 alone is not SSO. It is an authorization framework for delegated API access; it becomes an authentication mechanism only when OpenID Connect adds a standardized ID token and identity claims on top of it. Treating a bare OAuth access token as proof of identity is a classic design error.
SSO compared with related identity concepts
SSO sits close to several other Terms in the identity and access field, and they are frequently confused. SSO concerns where and how often authentication happens; it does not decide what a user may do afterwards, which remains the job of authorization models such as RBAC.
| Concept | Main question it answers | Relationship to SSO |
|---|---|---|
| Authentication | Who is this user | SSO centralizes it in the IdP |
| Authorization | What may this user do | Still enforced by each application or policy engine |
| MFA | Is the proof strong enough | Configured once at the IdP for all connected apps |
| Federation | Can another domain’s identity be trusted | The trust model that makes cross-domain SSO possible |
| Password manager | How to store many passwords | Fills credentials; does not remove them |
| Passkey | How to authenticate without a password | Often used as the login method at the IdP |
A password manager is sometimes described as “SSO”, but it keeps separate credentials for each application. True SSO removes those credentials from the applications entirely, which is why it also simplifies deprovisioning when an employee leaves.
Session lifetime and logout in SSO
Session design determines both the convenience and the risk of SSO. The IdP session lifetime is commonly set between 8 and 12 hours for a workday, with an idle timeout of roughly 15 to 60 minutes for sensitive environments, and periodic reauthentication for privileged actions. Access tokens in OpenID Connect are usually short-lived, often 5 to 60 minutes, and refreshed silently.
Logout is the weakest part of most deployments. Single logout requires the IdP to notify every relying party, and many applications ignore or fail these notifications. As a result, ending the IdP session often leaves application sessions alive until they expire, so short application session lifetimes and token revocation matter as much as the logout button.
| Parameter | Typical range | Effect of a longer value |
|---|---|---|
| IdP session lifetime | 8 to 12 hours | Fewer prompts, longer exposure if stolen |
| Idle timeout | 15 to 60 minutes | Unattended devices stay usable |
| Access token lifetime | 5 to 60 minutes | Revocation takes longer to take effect |
| Assertion validity window | 1 to 5 minutes | Larger window for replay |
| Refresh token lifetime | Hours to days | Persistent access without new login |
Security risks and common SSO mistakes
Because SSO concentrates trust, its failures are severe. The most damaging attacks target session cookies and tokens rather than passwords: an attacker who steals an IdP session cookie through malware or an adversary-in-the-middle proxy can bypass MFA entirely until the session ends. Phishing-resistant methods such as FIDO2 security keys and passkeys reduce this risk because they bind authentication to the legitimate origin.
| Weakness | Consequence | Remedy |
|---|---|---|
| Missing signature validation | Forged assertions accepted | Validate signature, issuer and audience strictly |
| XML signature wrapping in SAML | Attacker-controlled identity | Use hardened, maintained SAML libraries |
| Open redirect URIs | Token or code theft | Register exact redirect URIs |
| Long-lived sessions | Stolen cookies stay valuable | Shorter lifetimes, device binding |
| Local accounts left enabled | SSO policy bypassed | Disable local login or monitor it |
Another frequent mistake is treating SSO as complete while local fallback accounts remain active in each application. Those accounts escape central MFA and offboarding. A sound design keeps one or two break-glass accounts under strict control and disables all other local logins.
Understanding it simply
Think of SSO like a wristband at a festival. You show your ticket and ID once at the main gate, and you receive a wristband. After that, every stage and every tent lets you in by looking at the wristband instead of checking your ticket again.
At work, the main gate is the company login page, and the stages are email, chat, file storage and other tools. You sign in once, and every connected tool trusts that login. The catch is that the wristband becomes valuable: if someone steals it, they can enter everything, so the gate must check people carefully.
Applied in practice
A company with about 400 employees uses around 30 cloud applications, each with its own password. The help desk spends a large share of its time on password resets, and when people leave, some accounts are forgotten and stay active for months.
The security team connects all applications to one identity provider, using SAML 2.0 for older tools and OpenID Connect for newer ones, and enforces phishing-resistant MFA at the IdP. The IdP session lasts nine hours, application sessions last one hour, and local logins are disabled except for two monitored emergency accounts.
The result is that employees sign in once each morning, password reset requests fall sharply, and offboarding becomes a single action: disabling the IdP account cuts access to every connected application within the application session lifetime.