Authentication

Single Sign-On (SSO)

Single Sign-On (SSO) lets a user authenticate once with an identity provider and then access many independent applications without signing in again.

Last reviewed 5/30/2026

Key points

  • SSO is about session reuse across apps — it is not the same as multi-factor authentication (MFA).
  • Modern SSO uses SAML 2.0 (enterprise/legacy) or OpenID Connect on top of OAuth 2.0 (modern web/mobile).
  • The identity provider (IdP) authenticates the user; service providers (SPs) or relying parties (RPs) consume signed tokens.
  • SSO reduces password reuse and phishing risk, and is the foundation for SCIM provisioning and Zero Trust.
  • Federated SSO extends the same model across organizations (B2B SSO).

What is Single Sign-On?

Single Sign-On (SSO) is an authentication pattern where a user proves who they are once — to a trusted identity provider (IdP) — and is then automatically signed in to every other application that trusts that IdP. Instead of maintaining a separate username and password in Salesforce, Slack, GitHub, and a dozen internal apps, the user signs in to one place and applications consume a short-lived, cryptographically signed assertion that says "yes, this is alice@acme.com."

SSO is the backbone of modern workforce identity. It eliminates the password sprawl that drives credential reuse and phishing, gives security teams a single chokepoint for policy (MFA, conditional access, device trust), and is what makes joiner / mover / leaver automation through SCIM actually possible.

How SSO works

There are two dominant flavors in the enterprise today:

  1. SAML 2.0 — XML-based, designed in the early 2000s for browser-based enterprise SSO. The IdP signs an XML "assertion" and the user's browser POSTs it to the application. Still the default for older SaaS apps, on-prem systems, and most B2B federation.
  2. OpenID Connect (OIDC) — a thin identity layer on top of OAuth 2.0. The IdP issues a JSON Web Token (JWT) called an ID token. Native to modern web, mobile, and SPA architectures.

The high-level flow is similar in both:

  1. The user visits an application (the service provider in SAML, or relying party in OIDC).
  2. The app sees no session and redirects the browser to the IdP with an authentication request.
  3. The IdP authenticates the user — typically with password + MFA, a passkey, or an existing session cookie.
  4. The IdP returns a signed token to the application via the browser.
  5. The application verifies the signature, creates a local session, and lets the user in.

When buyers care about SSO

You need a dedicated SSO solution when:

  • You have more than ~10 SaaS apps and password management is becoming a help-desk burden.
  • You need to enforce MFA uniformly across apps that don't all support MFA natively.
  • You have to prove control of access for SOC 2, ISO 27001, HIPAA, or PCI audits.
  • You need fast deprovisioning when an employee leaves — turning off the IdP session and SCIM-driven user deletion in downstream apps.
  • You're starting a Zero Trust program — SSO is the front door where identity-aware policy is enforced.

Common misconceptions

  • SSO is not MFA. SSO is about session reuse; MFA is about how strongly the user authenticated at the IdP. You almost always want both together.
  • "Login with Google" on a consumer site is not enterprise SSO in the procurement sense — it's social login (a CIAM feature). Enterprise SSO refers to IdP-mediated federation governed by your IT team.
  • SSO does not eliminate passwords by itself. You still authenticate to the IdP. Phasing in passkeys at the IdP is what actually removes passwords.

How SSO relates to other identity categories

SSO is one component of a workforce identity platform. It pairs with:

  • MFA / passwordless at the IdP for strong authentication.
  • SCIM provisioning to push users and groups into downstream apps so SSO actually has accounts to log into.
  • IGA to govern who should have SSO access in the first place.
  • PAM for the smaller set of highly-privileged accounts that need step-up beyond standard SSO.

FAQ

Is SSO the same as a password manager?

No. A password manager stores per-app passwords and types them in for the user. The app still authenticates the user directly. With true SSO the downstream app doesn't store the user's password at all — it trusts a signed assertion from the IdP.

SAML or OIDC — which should I pick?

If you're integrating a modern web or mobile app and have the choice, use OIDC. If you're integrating an older enterprise SaaS app or an on-prem system, SAML is usually the only option supported. Most IdPs speak both.

Do I still need MFA if I have SSO?

Yes. SSO concentrates risk: one compromised IdP session unlocks many apps. Enforcing phishing-resistant MFA — ideally passkeys — at the IdP is what makes that concentration safe.

Standards & references