backend / authentication / 02_sso.md

SSO (Single Sign-On) — Common Interview Questions and Answers

3 interview angles 7 min read source

SSO (Single Sign-On) — Common Interview Questions and Answers

1. What is SSO (Single Sign-On)?

SSO lets a user sign in once and then access multiple applications or systems without logging in again. One identity provider (IdP) authenticates the user; applications trust that IdP and accept tokens or assertions instead of asking for a password.

Benefits: fewer passwords, better security (centralized auth and MFA), easier onboarding/offboarding, better UX.

2. How does SSO work at a high level?

  1. User opens Application A; not logged in → redirect to IdP (SSO provider).
  2. User signs in at IdP (once); IdP may use MFA.
  3. IdP redirects back to Application A with a token or assertion (e.g. SAML assertion, OIDC tokens).
  4. Application A validates the token and creates a local session (or uses the token).
  5. User opens Application B; Application B redirects to same IdP; IdP sees existing session → redirects back to B with token. No second login.

The IdP is the single place where the user proves their identity; apps trust the IdP.

3. What is an Identity Provider (IdP)?

An Identity Provider (IdP) is the system that authenticates users and issues identity tokens or assertions to applications. Examples: Okta, Auth0, Azure AD, Keycloak, Google Workspace, OneLogin.

The IdP holds credentials (or federates to another IdP), enforces MFA, and participates in SSO protocols (SAML, OIDC) to tell applications “this user is X.”

4. What is a Service Provider (SP) in SSO?

In SAML terminology, the Service Provider (SP) is the application that the user wants to use. The SP does not authenticate the user itself; it redirects the user to the IdP and then accepts a SAML assertion (or in OIDC, tokens) from the IdP to create a session.

So: IdP = “who are you?”; SP = “the app you’re using.”

5. What is the difference between SAML and OIDC for SSO?

Aspect SAML 2.0 OpenID Connect (OIDC)
Format XML assertions JSON; JWT ID/access tokens
Use case Enterprise SSO (often web) Web, mobile, APIs
Flow Browser redirect + POST OAuth 2.0 + ID token
Profile SAML 2.0 Web SSO OAuth 2.0 + identity layer
Common in Corp IdPs, legacy enterprise Modern apps, B2C, APIs

Both achieve SSO; OIDC is simpler for APIs and mobile and is widely used with OAuth 2.0.

6. What is SAML SSO flow in simple steps?

  1. User accesses SP (application); SP redirects browser to IdP with a SAML AuthnRequest (e.g. “please authenticate this user”).
  2. User logs in at IdP (if not already).
  3. IdP redirects back to SP with a SAML Response (XML) containing an Assertion (who the user is, attributes).
  4. SP validates the response (signature, audience, conditions), extracts identity and attributes, and creates a session.

All of this is typically over browser redirects (and POST for the response).

7. What is OIDC SSO flow in simple steps?

OIDC uses OAuth 2.0 Authorization Code flow (often with PKCE) and adds an ID token:

  1. User accesses app; app redirects to IdP (authorization endpoint) with scope=openid and response_type=code.
  2. User signs in at IdP (if needed); IdP redirects back with an authorization code.
  3. App exchanges code for tokens at IdP token endpoint: ID token (JWT, identity), access token (optional, for APIs), refresh token (optional).
  4. App validates ID token (signature, aud, exp), reads sub and other claims, and creates a session.

Same IdP session → same flow for other apps → no second login (SSO).

8. What is federated identity?

Federated identity means identity is managed in one place (or a few places) and trusted by many applications or organizations. Users have one (or a few) identities that work across systems. SSO is a result of federation: the IdP is in the “federation” and apps trust it. Federation can be within one org (internal SSO) or across orgs (e.g. “Login with Google” or B2B federation).

9. What is the difference between SSO and “Login with Google”?

  • “Login with Google” is social login (or “federated login”): your app delegates authentication to Google; one click to sign in. It is a form of SSO across many apps that use “Login with Google.”
  • SSO in enterprise often means: one corporate IdP (e.g. Okta, Azure AD); all internal apps use that IdP; user signs in once to the IdP and gets access to all those apps.

So: “Login with Google” = SSO where Google is the IdP; “Enterprise SSO” = one company IdP for many company apps.

10. What is JIT (Just-In-Time) user provisioning in SSO?

JIT provisioning: When a user signs in via SSO for the first time, the application creates the user account automatically using attributes from the IdP (e.g. email, name, groups). No separate “create user” step in the app.

Pros: No manual user creation; users get access as soon as they’re allowed at the IdP. Cons: You must map IdP attributes to app roles/permissions and handle updates (e.g. group changes) if needed.

11. What is SLO (Single Logout)?

Single Logout means logging out once ends the session at the IdP and (when supported) at all applications that participated in SSO. Without SLO, logging out of one app might not log the user out of the IdP or other apps.

Implementation: IdP supports a logout endpoint; app redirects there on logout; IdP invalidates its session and may redirect to other apps’ logout URLs so they clear their sessions too (SAML and OIDC have specs for this).

12. What security considerations are important for SSO?

  • Token/assertion validation: Verify signature, audience, expiry, issuer; prevent token substitution.
  • Redirect URLs: Whitelist exact callback/logout URLs; prevent open redirects and token leakage.
  • HTTPS: All IdP and app endpoints over TLS.
  • State / nonce: Prevent CSRF and replay in OAuth/OIDC flows.
  • IdP security: MFA, strong password policy, secure session handling at IdP.
  • Session handling in app: Secure cookies, timeouts, logout that clears local session and (if used) triggers SLO.

13. What is the difference between IdP-initiated and SP-initiated SSO?

  • SP-initiated: User goes to the application first; app redirects to IdP to authenticate; IdP redirects back to app. Most common.
  • IdP-initiated: User goes to an IdP portal (e.g. app launcher), picks an app; IdP sends the user to the app with an assertion/token. No visit to the app first.

Both achieve SSO; the starting point (app vs IdP) differs.

14. When would you choose SAML vs OIDC for SSO?

  • SAML: When the customer’s IdP only supports SAML (many enterprise IdPs), or when integrating with legacy enterprise SSO; browser-based web SSO.
  • OIDC: For new implementations, mobile apps, APIs, and when you want JWTs and OAuth 2.0 (access tokens for APIs). Simpler and more common in modern stacks.

Many IdPs support both; choose based on app needs and what the IdP supports.

15. What is a Relying Party (RP) in OIDC?

In OpenID Connect, the Relying Party (RP) is the application that relies on the IdP (OpenID Provider, OP) to authenticate the user. The RP redirects the user to the OP, receives the ID token (and optionally access/refresh tokens), and validates them. So “RP” in OIDC is the same idea as “SP” in SAML: the app that consumes the identity from the IdP.

Deep dives

For topical interview prep beyond the basics above, see sso/:

Interview angle

  • “What does SSO actually give you?” - one identity provider authenticates the user for many applications, so credentials, MFA policy and deprovisioning live in one place. The security win is centralised offboarding: disable once, access ends everywhere.
  • “SAML or OIDC?” - OIDC for anything new: JSON and JWT over HTTP, simpler to implement, native to mobile and SPAs. SAML is XML-based and entrenched in enterprise, so you’ll meet it whether or not you’d choose it.
  • “What breaks in SSO integrations?” - clock skew invalidating assertions, certificate rotation on the IdP side, incorrect audience or issuer validation, and group-to-role mapping drifting from what the IdP actually sends.
Previous
Authentication — Common Interview Questions and Answers