Single Sign-On (SSO)

Single sign-on lets a user authenticate once — against a central identity provider (IdP) — and access many applications without separate passwords. When you click "Sign in with Google" or your company laptop opens Slack, Jira, and GitHub without login prompts, that's SSO.

For users it means fewer passwords; for companies it means one place to enforce MFA, one switch to revoke a departing employee's access everywhere, and one audit trail. For SaaS builders it's a business milestone: "Do you support SSO?" is a standard checkbox on enterprise security questionnaires, and supporting it well is often what unlocks larger contracts.

TL;DR

How the Flow Works

The redirect dance is the same shape in SAML and OIDC (service-provider-initiated):

Step 5 is where security lives. The IdP's signature is the only thing standing between your app and anyone who can craft an XML document or JWT.

SAML vs OpenID Connect

Practical guidance: offer OIDC first, add SAML because enterprise customers will demand it. Legacy IdP configurations in large organizations keep SAML mandatory for real-world enterprise sales, but never hand-roll SAML XML validation — use a hardened library (samlify, python3-saml, Spring Security SAML) or a broker.

OIDC in One Example

OIDC is an OAuth authorization-code flow where the token response also includes an ID token:

Your app verifies the JWT signature against the IdP's published keys (JWKS endpoint), checks iss, aud, exp, and the nonce it sent, then trusts sub/email as the authenticated identity.

The Pieces Around Authentication

SCIM: Provisioning and Deprovisioning

SSO answers "can this person log in?" — it doesn't create or delete accounts. SCIM (System for Cross-domain Identity Management) is the companion REST protocol IdPs use to push user lifecycle events to your app:

Enterprise buyers ask for "SSO + SCIM" as a pair — deprovisioning is the security half. Without SCIM, offboarded employees keep working sessions and orphaned accounts.

JIT Provisioning

A lighter alternative: create the account on first successful SSO login ("just in time"), using assertion attributes (name, email, groups). Simple, but offboarding still depends on the IdP blocking login — combine with short sessions.

Session Lifetime and Single Logout

Your app's session is separate from the IdP's. Decisions to make deliberately:

Implementing SSO in a Multi-Tenant SaaS

The parts that surprise teams the first time:

  1. Per-organization configuration. Each enterprise customer brings their own IdP: metadata URL/certificates (SAML) or issuer + client credentials (OIDC). You need admin UI, storage, and testing flows per tenant.
  2. Home realm discovery. Given alice@acme.com, route her to Acme's IdP — usually by verified email domain.
  3. Account linking. Alice may already have a password account. Link by verified email at most — and beware: trusting an IdP-asserted email to take over an existing account is a real attack path if any tenant IdP can assert arbitrary domains. Restrict each tenant's IdP to its verified domains.
  4. Enforcement policy. Once an org enables SSO, do you block password login for its users? (Enterprise admins usually want yes.)
  5. Don't lock out admins. Keep a recovery path when a customer misconfigures their IdP.

💡 This per-tenant machinery is why brokers (WorkOS, Auth0/Okta CIC, Stytch) and IdP-library hybrids are so popular: they normalize SAML/OIDC differences behind one API and shift the certificate-rotation support burden.

Common Mistakes

Incomplete Assertion Validation

The top real-world SSO vulnerability class. Every assertion must be checked for: valid signature against the expected IdP key, iss (issuer), aud (this app), exp/NotOnOrAfter, and replay (nonce/assertion ID cache). SAML XML signature-wrapping attacks specifically exploit apps that verify a signature but not what was signed — another reason to use maintained libraries.

Trusting Unverified Email for Account Linking

"IdP says email = ceo@example.com, merge into that account" lets a hostile or misconfigured tenant IdP take over arbitrary accounts. Link only within domains verified for that tenant.

Confusing OAuth Authorization with Authentication

Plain OAuth 2.0 proves a client may access a resource — not who the user is. "Login with OAuth" done without OIDC's ID token/nonce has known impersonation pitfalls. Use OIDC for login.

Ignoring Deprovisioning

SSO without SCIM (or aggressive session expiry) means departed employees retain access until sessions die. Auditors notice.

Building Raw SAML by Hand

XML canonicalization, signature wrapping, entity expansion — SAML's attack surface is legendary. This is buy-not-build territory.

FAQ

Is "Sign in with Google" SSO?

Yes — consumer-grade OIDC SSO ("social login"). Enterprise SSO differs mainly in management: the customer's IT controls the IdP, enforces MFA, and expects SCIM, audit logs, and login enforcement.

SSO or MFA — which matters more?

They're complementary and usually arrive together: SSO centralizes authentication at the IdP, which is exactly where MFA gets enforced once for every connected app. Enterprise security reviews expect both.

What identity providers should I test against?

Okta, Microsoft Entra ID (Azure AD), and Google Workspace cover the large majority of enterprise customers; add OneLogin, Ping, and JumpCloud as they appear. Most offer free developer tenants.

How does SSO relate to passkeys/WebAuthn?

Orthogonal layers: passkeys are how the user authenticates to the IdP (replacing passwords); SSO is how that authentication propagates to apps. The strongest current setup is passkeys at the IdP + OIDC/SAML to the apps.

What should SSO cost as a SaaS feature?

Contentious ("SSO tax") — but the market reality is that SSO+SCIM typically gates an enterprise tier, partly because per-tenant IdP support has genuine ongoing cost.

Related Topics

References