How does Single Sign-On work, and how do SAML and OIDC differ?
Short answer
SSO centralizes authentication at an Identity Provider (IdP). When a user visits a Service Provider (the app), the app redirects to the IdP; the user logs in once, and the IdP returns a signed assertion or token vouching for their identity. SAML carries this as a signed XML assertion; OIDC carries it as a signed JSON ID token layered on OAuth 2.0. The app trusts the IdP's signature rather than handling passwords itself.
SSO questions test whether you understand federated trust: many applications outsourcing the act of authentication to one identity provider. Getting the SAML-vs-OIDC distinction right shows you've actually worked with it.
The core model
In SSO there are two roles: the Identity Provider (IdP) that authenticates users and the Service Provider (SP) — the application — that relies on it. When a user hits the app, the app redirects them to the IdP. If they're already logged in there, no prompt appears; otherwise they authenticate once. The IdP then sends the browser back to the app carrying a cryptographically signed statement that says "this is who the user is." The app verifies the IdP's signature and creates a local session. The user enters credentials once and reaches every federated app.
The big win is centralization: one place to enforce MFA, password policy, conditional access, and deprovisioning. Disable the account at the IdP and access everywhere dies at once.
SAML vs OIDC
- SAML 2.0 is the older enterprise standard. The IdP issues a signed XML assertion, typically delivered via a browser POST. It's mature and ubiquitous in B2B/enterprise, but XML is heavy and awkward for mobile and SPAs.
- OIDC (OpenID Connect) is an identity layer on top of OAuth 2.0. The IdP issues a JSON ID token (a JWT) alongside OAuth tokens. It's lightweight, JSON/REST-friendly, and the default for modern web, mobile, and API-driven apps.
Both rely on the SP verifying the IdP's signature to trust the assertion — that signature is the entire basis of trust.
The risk
SSO concentrates risk: the IdP becomes a single point of failure and a juicy target. If it's compromised (or a SAML assertion can be forged due to a parsing bug), the attacker gets everything. That's why IdPs demand the strongest, phishing-resistant MFA.
What interviewers look for
The IdP/SP redirect-and-signed-assertion model, the one-login-many-apps benefit, SAML (signed XML) vs OIDC (JWT over OAuth), signature verification as the root of trust, and awareness of the concentrated blast radius.
Likely follow-ups
- Why is OIDC often preferred over SAML for modern and mobile apps?
- What is the blast radius if the IdP is compromised, and how do you reduce it?
- How does the app verify a SAML assertion or an OIDC ID token is genuine?