SSO - System Design Guide | Interview Forge

Overview

Single sign-on (SSO) lets a user authenticate once with a central identity provider (IdP) and then access many applications without logging in again. Each application (service provider) trusts the IdP's signed assertion about who the user is, instead of managing its own passwords.

Enterprise SSO typically uses SAML 2.0 (older, XML-based) or OpenID Connect (modern, JSON/JWT-based). SSO improves security (one place for MFA, password policy, and offboarding) and user experience, but makes the IdP a critical dependency: if it is down, nobody can log in.

A festival wristband

You show your ticket and ID once at the main gate and get a wristband. Every stage and food tent checks the wristband instead of your ID. If security cuts your wristband, you lose access to everything at once.

When to use it

Companies with many internal and SaaS applications.
B2B SaaS selling to enterprises (customers require SSO).
A product suite where users move between apps (Google Workspace).
Centralized offboarding: disable one account, lose access everywhere.

Where it shows up in interviews

Enterprise SaaS

Recognize it when: customers want to use their own identity provider.

Design SSO for a B2B SaaS product
Design multi-tenant login

Product suite login

Recognize it when: one account across several apps.

Design Google account login across Gmail, Drive, YouTube

Where it is used in real software

Okta, Microsoft Entra ID, Google Workspace

Common enterprise IdPs that federate login to thousands of SaaS apps using SAML and OIDC.

SCIM provisioning

Alongside SSO, SCIM automatically creates and deactivates user accounts in apps when HR changes happen.

The SSO tax

Many SaaS vendors put SSO only in expensive enterprise plans because it is a must-have for large customers.

Key terms

Identity provider (IdP): Authenticates users and issues assertions or tokens.
Service provider (SP): The application that relies on the IdP.
SAML assertion: A signed XML document stating who the user is and their attributes.
Federation: Trust between separate organizations' identity systems.
SCIM: Standard API for provisioning and deprovisioning users.

How it works, step by step

1
User opens app A
App A has no session and redirects to the IdP.
2
IdP authenticates
User logs in with password + MFA; the IdP creates its own session.
3
IdP returns an assertion or token
Signed SAML assertion or OIDC ID token posted back to app A.
4
App A creates a local session
After verifying the signature and audience.
5
User opens app B
App B redirects to the IdP, which already has a session and immediately returns a token: no login prompt.

SAML vs OIDC

Both achieve SSO

Aspect	SAML 2.0	OpenID Connect
Format	XML assertions	JSON / JWT
Typical use	Enterprise web apps	Modern web, mobile, APIs
Mobile friendly	Poor	Good
Built on	Its own protocol	OAuth 2.0

NOWAspect: Format | SAML 2.0: XML assertions | OpenID Connect: JSON / JWT

New products should prefer OIDC, but B2B SaaS usually must support SAML too because many enterprises still require it.

Implementation

1import { Issuer, generators } from "openid-client";2 3const issuer = await Issuer.discover("https://idp.example.com"); // reads .well-known/openid-configuration4const client = new issuer.Client({5  client_id: "crm-app",6  client_secret: process.env.OIDC_SECRET!,7  redirect_uris: ["https://crm.example.com/callback"],8  response_types: ["code"],9});10 11app.get("/login", (req, res) => {12  const codeVerifier = generators.codeVerifier();13  req.session.codeVerifier = codeVerifier;14  res.redirect(client.authorizationUrl({15    scope: "openid email profile",16    code_challenge: generators.codeChallenge(codeVerifier),17    code_challenge_method: "S256",18  }));19});20 21app.get("/callback", async (req, res) => {22  const params = client.callbackParams(req);23  const tokens = await client.callback("https://crm.example.com/callback", params, { code_verifier: req.session.codeVerifier });24  const claims = tokens.claims(); // verified ID token: sub, email, name25  req.session.userId = await users.upsertFromIdp(claims.sub, claims.email);26  res.redirect("/");27});

Complexity and performance

First loginFull IdP login

Password + MFA.

Later appsRedirect only

No prompt while IdP session is valid.

Trade-offs

Convenience vs blast radius

One compromised IdP account reaches every app; enforce strong MFA and anomaly detection at the IdP.

IdP availability

An IdP outage blocks logins everywhere; existing app sessions keep working, so reasonable session lifetimes matter.

Variants and related techniques

Multi-tenant SSO

Each customer configures its own IdP; the login page routes by email domain.

Single logout

Logging out of the IdP signals every app to end sessions; hard to make fully reliable.

Common mistakes

Not validating the assertion's audience and signature.
Fix: Verify issuer, audience, signature, and expiry on every login.
Forgetting deprovisioning.
Fix: Use SCIM or short sessions so removed employees lose access quickly.

Interview questions

How does SSO work under the hood?

The application redirects to the identity provider, which authenticates the user and returns a signed assertion or ID token. The app verifies it and creates a local session. Other apps repeat the redirect, but the IdP's existing session makes it silent.

How would you add enterprise SSO to a multi-tenant SaaS?

Store per-tenant IdP configuration (SAML metadata or OIDC issuer), route login by email domain, map IdP identities to tenant users, and support SCIM for provisioning.

Practice problems

Problem	Difficulty	What it trains
Explain SSO between two apps and one IdP	Easy	Redirect flow.
Design per-tenant SSO for a B2B product	Hard	Configuration and mapping.