Single Sign-On (SSO) in System Design: IdP, SAML, OIDC & Token Flows (Visualized)

Single Sign-On (SSO) is an authentication mechanism that allows a user to log in once at a central Identity Provider (IdP) and then access multiple independent applications — called Service Providers — without being prompted to log in again for each one. Instead of every app managing its own credential store, SSO centralises authentication so that the credential check happens exactly once and the proof of identity is shared securely across the ecosystem.

SSO is ubiquitous in enterprise software: logging into your company's Google Workspace gives you access to Slack, GitHub, Jira, AWS Console, and dozens of internal tools — all from a single username and password challenge. The same pattern underpins consumer federation: «Sign in with Google» or «Sign in with Apple» are SSO flows that use your existing account at a well-known IdP to authenticate you to a third-party service.

Every SSO architecture has two distinct roles. The Identity Provider (IdP) is the authority that verifies the user's identity. It owns the credential store (passwords, MFA, biometrics) and issues signed tokens or assertions after a successful login. Well-known IdPs include Okta, Azure Active Directory, Google Workspace, Auth0, and Keycloak. The Service Provider (SP) is the application the user actually wants to use — your CRM, email client, payroll tool, or any web app. The SP trusts the IdP's assertions and grants access based on them without independently verifying credentials.

The IdP and each SP share a trust relationship established ahead of time — typically by exchanging signing certificates (SAML) or registering a client application with a client ID and secret (OIDC/OAuth 2.0). This pre-configured trust is what makes the subsequent token exchange verifiable and safe.

When a user navigates to a protected resource at a Service Provider for the first time, the SP has no session for them. It redirects the browser to the IdP's login page, including a parameter identifying which SP is requesting authentication. The user enters their credentials at the IdP. On success the IdP creates a central session, generates a signed assertion or token, and redirects the browser back to the SP with that token. The SP validates the signature, creates its own local session, and the user is in. The magic happens when the user then visits a second SP: the redirect to the IdP finds an existing central session, so the IdP skips the login prompt and immediately issues a token for the second SP. From the user's perspective they were never asked for a password again.

Two protocols dominate SSO deployments today: SAML 2.0 (Security Assertion Markup Language) and OIDC (OpenID Connect). SAML was designed in 2005 for enterprise web-browser federation. It carries assertions in XML envelopes and relies on browser redirects and HTTP POST bindings to shuttle them between IdP and SP. OIDC, finalized in 2014, is built on top of OAuth 2.0 and uses compact JWT (JSON Web Tokens) instead of XML. OIDC is the modern default for web and mobile apps; SAML remains common in legacy enterprise tooling.

In an OIDC Authorization Code Flow, the sequence is: (1) the SP redirects the browser to the IdP's /authorize endpoint with a response_type=code and a state nonce; (2) the IdP authenticates the user and redirects back to the SP's callback URL with a short-lived authorization code; (3) the SP's backend exchanges that code for an ID token, an access token, and optionally a refresh token via a direct server-to-server call to the IdP's /token endpoint; (4) the SP validates the ID token's signature against the IdP's public key and reads the user's claims (sub, email, roles, etc.). In a SAML flow the SP posts a SAMLRequest to the IdP, which signs a SAMLResponse XML blob and POSTs it back to the SP's Assertion Consumer Service (ACS) URL.

Without SSO, every application in an organisation maintains its own user database, password policy, and login screen. Users accumulate dozens of credentials. Password reuse and weak passwords become inevitable. IT teams spend a disproportionate amount of time on password resets. Compliance audits turn into nightmares. With SSO, the IdP becomes the single enforcement point: rotate a policy or revoke an account in one place and it instantly applies everywhere. The animation below shows the contrast starkly.

The IdP maintains a central session — typically a session cookie scoped to the IdP's domain — that tracks which user is currently authenticated. Each time the user visits a new SP, the browser automatically sends this cookie to the IdP, allowing the silent re-authentication described above. The central session has its own configurable lifetime (often 8–12 hours), after which the user must log in again regardless of which SP they are visiting.

Single Logout (SLO) is the complement to SSO: when the user signs out of any one SP (or from the IdP directly), the logout should propagate to all SPs that were authenticated in that session. In SAML, the SP sends a LogoutRequest to the IdP, which then sends LogoutRequest messages to every other SP that registered a session with that central session. In OIDC, SLO is more complex — the specification defines Front-Channel Logout (browser-side iframes) and Back-Channel Logout (server-to-server logout_token JWTs) as separate specs, and not all implementations support them fully. The result is that SLO is often the hardest part of SSO to implement correctly and is sometimes deliberately omitted in favour of short-lived tokens with fast expiry.

Reduced credential fatigue: Users manage one strong password plus MFA instead of dozens. Studies consistently show that credential reuse drops dramatically when users have fewer accounts to juggle. Centralised policy enforcement: MFA requirements, password rotation, and account lockout policies are defined once at the IdP and apply instantly to all connected apps. Faster onboarding and offboarding: provisioning a new employee means one account at the IdP; deprovisioning revokes access to every app in seconds — critical for offboarding security. Better audit trails: authentication events flow through a single system, making compliance reporting far simpler. Improved developer experience: new services delegate auth to the IdP rather than building it from scratch, reducing time-to-market and the surface area for auth bugs.

SSO's greatest strength — centralisation — is also its most significant risk. If the IdP is compromised, every connected application is compromised simultaneously. An attacker who steals the IdP's signing key can forge valid assertions for any user on any SP. An attacker who compromises a user's IdP account gains access to all of their apps at once. This is not a theoretical risk: the 2020 SolarWinds supply-chain attack included forging SAML tokens to pivot laterally across victim organisations' Microsoft 365 tenancies.

Mitigations include: enforcing phishing-resistant MFA (FIDO2/WebAuthn) at the IdP; rotating signing keys regularly and storing them in HSMs; monitoring for abnormal assertion issuance patterns; keeping the IdP's software patched and its admin surface minimal; and treating the IdP infrastructure with the same (or higher) security posture as your most sensitive application. Organisations with very high security requirements sometimes run separate IdPs per trust domain to limit blast radius.

Below is a representative OIDC client configuration in a Keycloak-style YAML file. The client_id and client_secret are registered at the IdP; the redirect_uris must be whitelisted exactly; the scopes declare which claims the SP wants in the ID token.

OAuth 2.0 is an authorisation framework: it lets a user grant a third-party application access to resources on their behalf (e.g., «allow this app to read my Google Drive»). It issues access tokens for API access but does not itself define who the user is. OIDC (OpenID Connect) is an authentication layer built on top of OAuth 2.0 that adds the ID token — a signed JWT that asserts the user's identity. SSO is the user experience pattern — one login, many apps — that OIDC (and SAML) implement. Think of it this way: OAuth 2.0 is the delegation framework, OIDC is the identity protocol, and SSO is the resulting user experience.

No. SSO without MFA creates an extremely high-value single point of failure: one compromised password instantly unlocks every connected application. Security teams universally recommend enforcing strong MFA — ideally phishing-resistant FIDO2/WebAuthn — at the IdP. The operational benefit of SSO (one credential) makes this doubly important: the stronger that one credential is, the safer the entire estate. Many enterprise IdPs allow you to step up authentication requirements (require re-auth with MFA) for access to particularly sensitive applications even within an existing SSO session.

Default to OIDC for any new integration. It has a richer library ecosystem, works natively on mobile and single-page applications via PKCE, and its JWT-based tokens are far easier to inspect and debug than SAML XML. Choose SAML only when the other party (a legacy enterprise SaaS or government system) requires it, or when your IdP does not support OIDC for a specific integration. If you must support both, most modern IdPs (Okta, Azure AD, Keycloak) let you expose the same identity source over both protocols simultaneously.