Single Sign-On (SSO)
An authentication architecture where one identity provider issues tokens that grant access to many downstream applications, reducing credential surface but concentrating blast radius.
Single Sign-On (SSO) is an authentication architecture in which one identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Ping, JumpCloud — holds the user’s credentials and issues short-lived assertions or tokens to every downstream application the user accesses. The user signs in once; the IdP vouches for them everywhere else.
SSO is built on two interoperable standards:
- SAML 2.0. XML-based assertions, ubiquitous in B2B SaaS, still the dominant protocol for enterprise web applications.
- OpenID Connect (OIDC). JSON/JWT-based, built on top of OAuth 2.0, the modern default for new applications and mobile/SPA flows.
- Just-in-time (JIT) provisioning. First sign-in auto-creates the downstream account using attributes from the SAML/OIDC assertion.
- SCIM typically pairs with SSO to handle the lifecycle (provision, update, deprovision) — without it, “SSO” still leaves orphan accounts behind when someone leaves.
The security case for SSO is strong: one place to enforce MFA, one password to rotate, one audit log for sign-ins. It collapses the credential surface that drives password reuse and credential stuffing.
But SSO concentrates blast radius. When the IdP is compromised — see the 2022 Okta support-system incident and the 2023 Okta customer-support breach — every connected SaaS becomes reachable in a single hop. Three patterns the security team needs to watch:
- MFA factor strength at the IdP. If the IdP accepts push or SMS, the entire estate inherits that weakness. Migrate IdP-side to FIDO2 / passkeys before downstream apps.
- OAuth grants from the SSO session. Once signed into Google Workspace, a user can grant a third-party app broad scopes — OAuth phishing bypasses MFA entirely.
- SSO bypass on legacy apps. Many SaaS keep a local-password backdoor. Disable it explicitly per app; auditors increasingly check.
SSO is necessary but not sufficient. Treat the IdP as tier-zero infrastructure, instrument the sign-in stream, and pair it with behavior monitoring on the apps downstream.
Related terms
- Multi-factor authentication (MFA)An authentication scheme that requires two or more independent factors — something you know, have, or are — to verify a user, raising the cost of credential theft.
- FIDO2 / PasskeysOpen authentication standards using device-bound asymmetric cryptography to deliver phishing-resistant sign-in — the practical answer to MFA fatigue and adversary-in-the-middle phishing.
- OAuth grantAn access token a user issues to a third-party application via OAuth, giving that app standing permission to read or write data inside another SaaS — often beyond MFA, often forever.
- OAuth phishing / consent phishingAn attack that tricks a user into granting a malicious third-party app persistent OAuth access to their mailbox, files, or workspace — bypassing MFA entirely.
- Credential stuffingAn automated attack that replays username/password pairs leaked in third-party breaches against unrelated services, exploiting password reuse to take over accounts at scale.