Single Sign-On (SSO)

Single Sign-On lets someone authenticate once and carry that proof of identity into a whole set of independent applications, instead of each app checking a password of its own. A central identity provider does the verifying; every connected application simply trusts what it says. That's the core idea I keep coming back to when I explain SSO to a team: it doesn't eliminate authentication, it just moves all of it to one well-guarded place and reuses the result.

SSO lives inside the broader Identity & Access Management discipline, and it answers one narrow question — is this really them? — a single time, then passes that answer around as a short-lived, signed token rather than asking again at every door.

Why It's Worth Getting Right

SSO is unusual among controls because it pulls security and usability in the same direction rather than opposite ones.

• Fewer passwords to steal. One strong credential at the identity provider beats a dozen weak, reused ones scattered across apps.
• One place to enforce policy. MFA, conditional access, device checks, and password rules live at the IdP and apply everywhere at once, instead of being reimplemented per app.
• Offboarding that actually works. Disable the central identity and every federated app loses access in the same moment — no orphaned logins left behind.
• Less support overhead. Fewer passwords means fewer resets and lockouts.
• A single chokepoint to watch. Every authentication event flows through one place, which makes anomaly detection and audit far more tractable.

The trade-off is concentration: the identity provider becomes the highest-value target in the whole environment. Whatever breaks in, breaks in everywhere — which is exactly why the engineering around it deserves real scrutiny, not a checkbox.

The Vocabulary Worth Knowing

Underneath all of it is one mechanism: delegated trust. The application never touches the password — it accepts a signed token as proof and validates that signature instead of the credential itself.

What Actually Happens at Login

Most modern SSO follows the same redirect dance, whatever the app:

Steps 1–4 log into the first app through the identity provider; steps 5–6 show why a second app never has to ask again.

1. Someone opens an app and asks for something that needs a login.
2. The app finds no valid session and bounces the browser to the identity provider.
3. The IdP checks who they are — password, passkey, MFA, device posture, whatever policy demands.
4. On success, it issues a signed token and sends the browser back to the app.
5. The app checks the token's signature, issuer, audience, and expiry, then starts a local session.
6. The next federated app they visit finds the IdP already recognizes them — no second prompt. That's the "single" in Single Sign-On.

Every bit of that security rests on the token itself: signed by the IdP, scoped to the one application it's meant for, short-lived, and checked strictly on arrival.

The Protocols, and Why They're Not Interchangeable

A handful of open standards carry all of this, and the most common mistake I see is treating them as interchangeable when they solve different problems — some prove who someone is, others grant what they can access. Mixing those up is where a lot of real SSO bugs come from.

SAML 2.0

A mature, XML-based standard from 2005 that's still the default in a lot of enterprise and B2B workforce SSO. The IdP hands over a signed XML assertion describing the user, and the application reads it. It's well supported by legacy and enterprise SaaS, though its XML tooling is heavier to work with than the newer JSON-based options.

OAuth 2.0 / 2.1 — Authorization, Not Authentication

OAuth grants scoped access to a resource on someone's behalf — "let this app read your calendar" — and issues access tokens to do it. On its own, it never tells an application who the user is, which is a distinction worth holding onto carefully since conflating it with authentication is a recurring source of real vulnerabilities. OAuth 2.1 gathers a decade of OAuth 2.0 hardening into one document rather than introducing new behavior: PKCE becomes mandatory for every authorization-code flow, the implicit grant and password-credentials grant are dropped, and redirect URIs must match exactly. In practice: authorization code with PKCE for anything involving a person, client credentials for machine-to-machine calls, and the device grant for input-constrained hardware.

OpenID Connect — Authentication on Top of OAuth

OIDC is a thin authentication layer built on OAuth 2.0. It adds an ID token — a signed JWT — that actually states who the user is. It's the modern default for consumer and cloud-native SSO: JSON-based, REST-friendly, and simpler to get right than SAML. The short version: OAuth authorizes, OIDC authenticates. If an application needs to know identity rather than just access, OIDC or SAML is the right tool — OAuth by itself isn't.

Where It Breaks

Concentrating trust means the failure modes concentrate too. The ones I design against first:

• The IdP as a single point of failure. Down, and everyone's locked out. Compromised, and an attacker can reach everything. Its availability and hardening are business-critical, not just an IT concern.
• Token theft and replay. Short lifetimes, sender-constrained tokens, HttpOnly storage instead of anything browser-script-accessible, and strict transport security all cut this down.
• Session hijacking at the IdP. A long-lived, loosely protected session there is a master key — bound it with reasonable lifetimes and re-authentication for sensitive actions.
• Phishing the one credential that matters. Because it unlocks everything, it's the most lucrative thing to phish — the core reason phishing-resistant authentication earns its keep.
• Sloppy validation. Loose redirect-URI checks, skipped audience or signature checks, and overly broad scopes are recurring root causes behind real SSO breaches. Every token deserves a strict check: signature, issuer, audience, expiry, nonce.
• Federation sprawl. Every federated relationship is a trust edge. Federate without governance and the blast radius quietly grows.

How I'd Design It

• Phishing-resistant MFA at the IdP — FIDO2/passkeys or hardware keys, not SMS or TOTP codes alone.
• Conditional access layered on top — device posture, location, and risk signals evaluated at login, not just the password.
• Short-lived tokens, rotated refresh tokens — sender-constrained wherever the workload warrants it.
• Strict validation on the service-provider side — never trust an assertion that hasn't been checked.
• Centralized logging for authentication events, watching for impossible travel, token anomalies, and mass-access patterns.
• A tested recovery path for IdP outages and lost devices, decided before rollout — not improvised during an incident.
• Federation governance — review connected applications and trust relationships on a schedule, and deprovision aggressively.
• Least privilege on scopes and claims — issue only the attributes an application genuinely needs.

Passkeys Don't Replace SSO — They Sit Underneath It

Passkeys (FIDO2/WebAuthn) are changing the authentication factor that sits underneath SSO. They're phishing-resistant because the cryptographic exchange is bound to the real origin domain — a fake login page simply can't replay it — and the private key never leaves the user's device.

The distinction worth holding onto: passkeys govern how someone proves identity, and SSO protocols like SAML and OIDC govern how that proof gets carried to applications afterward. The passkey authenticates the person to the identity provider; the IdP then federates that identity out to everything connected. Passkeys strengthen the front door — SSO still distributes the keys to every room behind it. Rolling passkeys out means planning for lost-device recovery and for legacy applications that don't yet speak WebAuthn.

One passkey secures the one connection that matters — user to IdP. The IdP then fans federated trust out to every app on its own, separate rails.

Glossary