Single Sign-On (SSO)

What is SSO?

Single Sign-On lets a user authenticate once with a central identity provider (IdP) and access many applications without re-entering credentials. Each app federates trust to the IdP via SAML or OIDC: the app redirects to the IdP, the IdP authenticates and returns a signed assertion/token, the app trusts it. Okta, Entra ID, Google Workspace, and Ping are the common IdPs; nearly every SaaS product offers SSO integration.

Why it’s a security decision, not just convenience

SSO consolidates authentication, and consolidation cuts both ways. The wins are real: one place to enforce MFA (turn on phishing-resistant MFA at the IdP and every app inherits it), instant deprovisioning (disable the IdP account and access to everything evaporates — the single most important offboarding control), fewer passwords to phish or reuse, and centralized audit. The concentrated risk is equally real: the IdP becomes the keys to the kingdom — compromise it and every federated app falls, which is why IdP admin accounts get the strongest possible protection and why IdP availability becomes a company-wide dependency.

The design details that bite

Session lifetime governs how fast revocation propagates: apps mint their own local sessions after SSO, so a disabled IdP account still has access until those local sessions expire — short lifetimes or token introspection close the gap (the same problem that makes Single Logout hard). SCIM provisioning should accompany SSO so accounts are created and deleted automatically, not just authenticated. And plan for IdP outages: break-glass access paths for when the front door itself is down.

What people get wrong

• SSO without MFA at the IdP — you’ve centralized a single-factor login into one high-value target.
• Authentication without provisioning: SSO logs users in but orphaned accounts linger without SCIM.
• Ignoring local session lifetimes and assuming IdP disable is instant everywhere.

Primary source: NIST SP 800-63B — Digital Identity Guidelines