Single Sign-On (SSO) Explained

Single sign-on (SSO) lets a user authenticate one time with a central identity provider and then access many separate applications without logging in again to each. Instead of every application maintaining its own passwords, they delegate authentication to a trusted authority that vouches for the user. This model improves user experience, centralizes security controls, and reduces password sprawl, but it also concentrates risk in the identity provider, which becomes the key to every connected system.

Core Roles in an SSO System

SSO relies on a trust relationship between two kinds of parties.

• Identity Provider (IdP): the authority that authenticates users and issues assertions or tokens confirming their identity. Examples include enterprise directory services and cloud identity platforms.
• Service Provider (SP) or Relying Party: the application the user actually wants to use. It trusts the IdP to perform authentication and consumes the token it issues.

This delegation is called identity federation when the parties belong to different security or organizational domains. Federation is what lets one corporate login open dozens of third-party SaaS tools. The applications never see the user's password; they see only a signed statement from the IdP.

How an SSO Login Flow Works

Although protocols differ in detail, browser-based SSO follows a common redirect pattern. Consider a user opening an application without an active session:

1. The user requests a protected resource at the service provider.
2. The SP finds no local session and redirects the browser to the IdP with an authentication request.
3. The IdP checks for an existing session. If none exists, it prompts for credentials and, ideally, multi-factor authentication.
4. On success, the IdP creates its own session and issues a signed token or assertion, redirecting the browser back to the SP.
5. The SP validates the token's signature and claims, then establishes a local application session for the user.

The browser redirects trace out concretely as:

1. GET  https://app.example.com/home           (no local session)
2. 302  https://idp.example.com/sso?request=... (SP sends authn request)
3. (user authenticates at the IdP)
4. POST https://app.example.com/acs            (signed assertion/token)
5. SP validates signature + audience, sets its session cookie

The crucial efficiency comes at step three. If the user already has a live session with the IdP from a previous login, the IdP can issue a new token immediately without prompting, so the second and third applications open seemingly instantly. That single IdP session is the heart of the single sign-on experience.

The Trust Anchor: Signed Tokens

Everything hinges on the SP being able to trust a token it did not create. This is achieved with cryptographic signatures. The IdP signs each assertion with a private key, and the SP verifies it using the IdP's published public key or certificate.

A validating SP must check more than the signature alone:

• Signature: confirms the token came from the trusted IdP and was not altered.
• Audience: confirms the token was intended for this specific SP, not another.
• Expiry and timestamps: confirms the token is within its valid lifetime and not replayed.
• Issuer: confirms the token originated from the expected IdP.

Skipping any of these checks creates real vulnerabilities. An SP that ignores the audience claim, for example, may accept a token minted for a different application, allowing token reuse across services.

SSO Protocols

Several standards implement SSO, and they suit different environments. The differences are covered in depth in SAML vs OAuth vs OpenID Connect, but in brief:

• SAML uses XML assertions and is common in enterprise web SSO and SaaS integrations.
• OpenID Connect (OIDC) builds an identity layer on OAuth 2.0 using JSON Web Tokens, and is favored for modern web and mobile applications.
• Kerberos provides ticket-based SSO inside a network domain, using tickets rather than browser-borne tokens.

Choosing a protocol depends on whether you are federating with external SaaS, building a mobile app, or providing seamless access across an internal corporate network.

Security Benefits and Concentrated Risk

SSO delivers clear security advantages, but only when the central point is hardened.

Benefits

• Centralized policy. Password rules, MFA enforcement, and conditional access are configured once and applied everywhere.
• Faster deprovisioning. Disabling a leaving employee's IdP account revokes access to all connected applications at once, closing a common gap where orphaned accounts linger.
• Fewer passwords. Users maintain a single strong credential instead of reusing weak passwords across sites, which reduces exposure to credential-stuffing attacks.

Risks

• Single point of failure. If the IdP is unavailable, every dependent application can become inaccessible.
• High-value target. Compromising the IdP or its signing key can grant an attacker access to all federated services, so IdP administrators and signing keys demand the strongest protection.
• Session hijacking impact. Because one session unlocks many applications, stealing that session token is especially damaging, making robust session management essential.

Hardening an SSO Deployment

Sound SSO engineering focuses on protecting the IdP and the tokens it issues.

• Enforce phishing-resistant MFA on the IdP itself, since it guards every downstream application.
• Rotate and safeguard signing keys, and monitor for unexpected token issuance.
• Set short token lifetimes and validate audience, issuer, and expiry on every SP.
• Implement single logout where feasible so ending the IdP session terminates application sessions.
• Log authentication events centrally to detect anomalous access patterns across services.

Done well, SSO shrinks the overall attack surface by replacing many weak local logins with one strongly defended authority. Done poorly, it hands an attacker a master key. The difference lies almost entirely in how rigorously the identity provider and its tokens are protected. You can find related guidance across K0G.

Key Takeaways

• SSO lets users authenticate once with an identity provider and reach many service providers through federated trust.
• Applications never receive the password; they validate a signed token and must check signature, audience, issuer, and expiry.
• A single live IdP session is what makes subsequent application logins seamless.
• SSO centralizes security policy and deprovisioning but concentrates risk in the identity provider.
• Protect the IdP with strong MFA, guarded signing keys, short token lifetimes, and thorough logging.