Single Sign-On (SSO): one login, many applications

From “who are you” to “and now everywhere”

The previous articles were about proving identity — factors, MFA, biometrics. Single Sign-On is about what you do with that proof once you have it: reuse a single authentication across many applications so the user does not re-enter credentials at every door.

SSO is one of the highest-leverage patterns in all of identity. Done well it improves user experience and security at the same time — a rare combination. Done carelessly it concentrates risk so tightly that one stolen session unlocks a company’s entire application estate. This article is about getting the leverage without the landmine.

It builds directly on the protocols module: SAML, OAuth, and OIDC are the languages SSO speaks. If those are fuzzy, keep them open in another tab — here we assume you know what an assertion and an ID token are, and focus on the architecture and trade-offs of stitching many apps to one login.

What SSO actually is

Single Sign-On is an arrangement where a user authenticates once against a central Identity Provider (IdP), and then reaches multiple independent Service Providers (SPs / relying parties) without authenticating again. Each application does not verify a password itself; it trusts a signed assertion from the IdP that says “this is Sara, authenticated at this time, at this assurance level.”

The mechanism rests on two sessions people often conflate:

• The IdP session — the “master” session created when you first log in. It lives at the identity provider (typically a browser cookie on the IdP’s domain).
• The SP sessions — a separate session each application creates for you after it accepts the IdP’s assertion. These are independent and locally managed.

That distinction is the key to everything that follows. SSO is easy to reason about at login — one master session mints many app sessions — and hard at logout, precisely because those app sessions are independent.

sequenceDiagram
  accTitle: SP-initiated Single Sign-On flow
  accDescr: A user requests an application. The application, finding no local session, redirects the browser to the identity provider. The identity provider authenticates the user with multi-factor authentication, establishes its own session, and returns a signed assertion to the application. The application validates the assertion and creates a local session. When the user later opens a second application, it redirects to the identity provider, which already has a session and returns an assertion immediately without asking for credentials again.
  actor U as User (browser)
  participant A as App / SP
  participant I as Identity Provider
  U->>A: Request protected page
  A-->>U: No session — redirect to IdP
  U->>I: Authentication request
  I->>U: Prompt: credentials + MFA
  U->>I: Provides factors
  I->>I: Create IdP session
  I-->>U: Signed assertion (redirect back)
  U->>A: Deliver assertion
  A->>A: Validate signature, create SP session
  A-->>U: Access granted
  Note over U,I: Later — second app
  U->>I: Auth request (IdP session already exists)
  I-->>U: Assertion immediately — no re-login

The three flavors of SSO

“SSO” names a goal, not one technology. Three architectures dominate, and mixing them up leads to bad design conversations.

Web SSO

The default meaning today: browser-based applications federated to one IdP over SAML or OIDC. One corporate login (Entra ID, Okta, Ping) unlocks dozens of SaaS apps; one campus login opens every university system. The IdP holds the session; each SP trades a redirect for an assertion. This is where most modern effort goes and what the diagram above depicts.

Enterprise SSO

Single sign-on extended beyond the browser to desktop and legacy applications inside a network — thick clients, on-prem systems, things that never spoke SAML. Historically delivered by Kerberos with Active Directory (log in to Windows, get a ticket, and domain-joined apps accept it silently) or by an enterprise-SSO agent that injects stored credentials into apps that only understand username/password. It is the messier, older cousin of Web SSO, still very much alive in large enterprises with legacy estates.

Social SSO

“Log in with Google / Apple / Facebook.” A consumer identity provider acts as the IdP for third-party sites, over OIDC. It removes signup friction and offloads password management to a provider the user already trusts. The trade-offs are different from the workforce case: you inherit that provider’s account-security decisions, you create a dependency on them, and you must think about what happens if a user loses access to that social account. Offering more than one option, plus a native fallback, is the usual mitigation.

IdP-initiated vs SP-initiated

The diagram above showed an SP-initiated flow: the user starts at the application, which bounces them to the IdP. There is a second pattern worth knowing because it behaves — and fails — differently.

• SP-initiated: the user lands on the app first (a bookmark, a deep link), finds no session, and gets redirected to the IdP to authenticate, then back. This is the common, recommended flow. Because the app started the exchange, it can validate that the returned assertion answers its specific request.
• IdP-initiated: the user starts at the IdP (a portal or “app launcher”), clicks a tile, and the IdP sends an unsolicited assertion straight to the app. Convenient, but riskier: the app receives an assertion it never asked for, so it cannot correlate it to a pending request — which historically opened the door to assertion-replay and login-CSRF style attacks. OIDC largely discourages the unsolicited pattern for this reason.

The practical guidance: prefer SP-initiated, and if you must support IdP-initiated (many enterprise portals rely on it), harden it with strict assertion validation, tight time windows, and replay protection. Knowing which flow you’re in explains a lot of “why did this SSO login behave strangely” incidents.

How the trust is established

SSO only works because each SP has a pre-established trust relationship with the IdP. That trust is not magic — it is concrete configuration, and it is where a surprising number of failures and vulnerabilities live.

• Metadata exchange. In SAML, IdP and SP swap metadata (entity IDs, endpoint URLs, and public signing certificates). This tells each side where to send messages and how to verify signatures. OIDC does the equivalent through a discovery document (.well-known/openid-configuration) and dynamic or manual client registration.
• Signing keys. The IdP signs assertions with its private key; the SP verifies with the IdP’s public certificate. If that certificate expires (a classic outage cause) or is swapped without coordination, every login breaks at once. If an SP is careless about which key it trusts, forged assertions become possible — the essence of the Golden SAML attack, where an adversary who steals the IdP signing key can mint valid assertions for anyone.
• Attribute mapping. The assertion carries claims (email, groups, roles). The SP maps these to its own users and permissions. Get the mapping wrong — trusting an unverified email claim, over-trusting a group attribute — and you have an authorization bug riding on a working login.
• Just-in-time provisioning. Many SPs create a local account on first SSO login from the assertion’s attributes (JIT provisioning), so users don’t have to be pre-created. This pairs with SCIM (from the protocols module) for the fuller lifecycle: SSO handles authentication, SCIM handles provisioning and deprovisioning of the account itself. Confusing the two is common — SSO logging a user in does not, by itself, remove their account when they leave; that’s SCIM’s job.

The benefits: why nearly everyone adopts it

SSO is rare in that its usability and security cases point the same direction.

• User experience. One login instead of dozens. No juggling app-specific passwords, no re-authenticating all day. This is the visible win and the one that gets it funded.
• Less password fatigue → fewer weak habits. When people manage one strong credential instead of forty, they stop reusing passwords, stop writing them on sticky notes, and stop picking Company2026! variants. You remove passwords from the individual apps entirely — an app federated to your IdP has no password to leak.
• Stronger, centralized security posture. You enforce MFA, conditional access, password policy, and risk-based rules once, at the IdP, and every connected app inherits them. Add a new phishing-resistant requirement and it protects the whole estate at once.
• Faster, safer lifecycle. Onboarding grants access through one identity; offboarding is the big one — disable the central identity and the leaver loses every connected app at once, instead of hoping forty separate accounts get cleaned up (they never all do).
• Auditability. Authentication events converge on one system, so your logs, anomaly detection, and ITDR have a single high-value stream to watch.

What SSO is not: adjacent concepts

SSO gets confused with three neighbors, and keeping them distinct sharpens your design conversations.

• SSO is not a password manager. A password manager still gives each app its own password; it just stores and autofills them for you. Every app keeps a separate credential that can individually leak, and there is no central point to disable at offboarding. SSO removes the per-app password entirely by making apps trust the IdP. A password manager is a coping mechanism for a world without SSO; SSO is the structural fix.
• SSO is not “same sign-on.” Some setups sync the same username and password to many apps (via a directory) so it feels unified — but each app still authenticates independently against its own copy. True SSO has one authentication event and one session that the others trust; same-sign-on has many authentications that merely share a credential.
• SSO is not authorization. Logging in through the IdP proves who you are; it does not decide what you may do inside each app. That is authorization — the subject of the modules that follow — and an app must still enforce its own permissions on top of a successful SSO login. Treating a valid SSO assertion as if it granted access is a classic mistake.

When an app can’t do SSO

Real estates are never 100% federated, and the gaps are where risk pools. Some apps don’t support SAML or OIDC (older or cheaper software), some vendors put SSO behind a premium tier (the so-called “SSO tax”), and some legacy systems only understand a local username and password. These exceptions matter because they are exactly the accounts that escape the benefits above: they keep their own passwords, they are missed at offboarding, and they don’t inherit your central MFA.

Practical handling: push vendors for standards support and budget for the SSO tier on anything sensitive; where a true SSO integration is impossible, fall back to a password manager or privileged-access vault with per-app MFA and deliberate offboarding runbooks; and inventory the exceptions so you know precisely which accounts sit outside the federated, centrally-governed core. The goal isn’t perfection — it’s knowing where your coverage ends.

The core risk: breaking the chain

Every benefit of SSO comes from concentration — and concentration is also its defining danger. When many applications trust one identity provider, that provider becomes a single point of compromise. Break it, and you break everything downstream. Practitioners call this breaking the chain; risk people call it blast radius.

The failure modes follow directly:

• Phishing the IdP login. An attacker no longer needs to phish forty apps — they phish the one login that unlocks all of them. The IdP is now the single most valuable credential target in the organization.
• A stolen IdP session. If an attacker steals the master session (session-hijacking, a stolen token, malware on the device), they inherit SSO into every connected app without re-authenticating — the same frictionlessness that helps the user helps the attacker.
• Availability. If the IdP is down, users cannot log in to anything federated to it. SSO makes the IdP a business-critical dependency, not just a security one.
• Misconfigured trust. A single bad federation setting — a lax assertion validation, a stale signing certificate, an over-broad trust — can expose many SPs at once.

The Golden SAML technique and several high-profile IdP-related breaches are exactly this risk realized: compromise the identity layer and lateral movement into everything federated is nearly free.

Mitigating the blast radius does not mean abandoning SSO — the alternative (dozens of independent passwords) is worse. It means (1) hardening the IdP disproportionately, (2) keeping master sessions short and re-verifying at the app level for high-value actions via step-up, and (3) not blindly trusting the SSO session forever — which is exactly the continuous verification mindset of Zero Trust.

How long should the master session live?

A design lever people underuse: the lifetime of the IdP’s master session sets how often users face a real login and, crucially, bounds how long a stolen master session stays useful. Too long (weeks of “stay signed in”) and the frictionless SSO experience becomes a frictionless attacker experience; too short and you re-authenticate people constantly and erode SSO’s whole benefit.

The modern answer is not one fixed number but a risk-based one, tying back to the adaptive ideas from the factors article: a low-risk session on a managed, compliant device can last comfortably, while a session on an unmanaged device, from a new location, or seeking sensitive resources gets a shorter leash and more frequent re-verification. Pair a sane absolute lifetime with step-up at the app for high-value actions, and you get the convenience of a long-lived SSO session without granting it unlimited power. This is exactly where SSO stops being “log in once forever” and starts being “log in once, but keep proving it’s still you when it matters” — the bridge to Zero Trust.

Single Logout: the hard, neglected half

If login is SSO’s triumph, logout is its unsolved problem. Logging in once is elegant. Logging out once — Single Logout (SLO) — means propagating a “session over” signal to every application the user opened, each holding its own independent session, often on different domains. That is genuinely hard, and it is why so many “SSO” deployments quietly implement no real SLO at all.

Why it is hard

• Independent SP sessions. Remember the two-session model: killing the IdP session does not automatically kill the app sessions it spawned. Each SP must be told, and must comply.
• The IdP often doesn’t know who’s still open. It must track every SP a user established a session with during this master session, then reach each one to invalidate — bookkeeping that is easy to get wrong.
• Front-channel logout works by redirecting the browser through a chain of per-app logout URLs (often via hidden iframes). It is fragile: it breaks when a tab is already closed, when third-party cookies are blocked (increasingly the browser default), or when any app in the chain is slow or unreachable.
• Back-channel logout has the IdP call each SP’s logout endpoint server-to-server (OIDC Back-Channel Logout, SAML SLO). More robust, but only works if every SP implements and honors that callback — and many don’t.
• Any missed app leaves a live session. Logout is only as complete as the weakest participant. One SP that ignores the signal, and the user who thinks they logged out everywhere still has an open door — on a shared or public computer, that is a real exposure.

What good practice does about it

• Short session lifetimes so a missed logout self-heals quickly — often more effective in practice than trying to make SLO perfect.
• Back-channel logout where the protocol and SPs support it, treated as the primary mechanism, with front-channel as best-effort cleanup.
• Re-authentication for sensitive actions so a lingering session cannot, by itself, do damage.
• Clear UX about what “log out” actually did — logging out of the app vs the whole SSO estate are different acts, and users deserve to know which one happened.

A day in the life: Sara across the estate

Concrete flows make the two-session model click. Sara is a nurse at a hospital that federates its apps to one IdP.

• 8:00 — first login. She opens the scheduling app. It has no session for her, so it redirects to the IdP. She authenticates with a passkey (phishing-resistant) plus a compliant, managed laptop. The IdP creates its master session and returns a signed assertion; the scheduling app validates it and creates its own session. Elapsed: a few seconds.
• 8:05 — second app, no login. She opens the records system. It redirects to the IdP — but the master session already exists, so the IdP returns an assertion immediately, without prompting. To Sara it feels like the app “just knew her.” That silent second login is the whole point of SSO — and the reason a stolen master session is so dangerous.
• 12:30 — a sensitive action. She tries to export a batch of patient records. The app doesn’t rely on the hours-old login; it triggers step-up, asking her to re-verify with her passkey right now. The session was valid, but the action warranted fresh proof.
• 17:00 — she leaves for the day on a shared workstation and clicks “log out.” The IdP session ends and, where back-channel logout is wired up, the connected apps are told to end their sessions too. Any app that doesn’t honor the callback keeps a live session — which is exactly why the workstation also enforces a short idle timeout as a backstop.
• Three weeks later — she changes employers. IT disables her one central identity. Instantly she can authenticate to nothing federated to the IdP, and SCIM deprovisioning removes her local accounts. Compare that to a non-SSO world where forty separate accounts would have to be found and closed by hand.

Every SSO concept — master vs app sessions, silent re-login, step-up, logout propagation, one-switch offboarding — appears in a single ordinary day.

Common SSO misconfigurations

Most SSO incidents are not exotic protocol breaks; they are configuration mistakes. The recurring ones are worth memorizing as a review checklist:

• Weak or missing assertion validation. Not checking the signature, the audience (aud), the intended recipient, the time window (NotBefore/NotOnOrAfter), or replay. Each omission turns a stolen or forged assertion into a valid login.
• Over-broad or spoofable attribute trust. Trusting an unverified email claim to match accounts lets an attacker who controls a matching email hijack the mapping. Trusting a group/role claim without limiting which IdP can assert it is similar.
• IdP-initiated left wide open. Accepting unsolicited assertions without replay protection or tight timing, as noted above.
• No MFA on the IdP itself. Federating forty apps to an IdP protected only by a password recreates the blast-radius risk in its worst form — one phished password unlocks everything.
• Expired or mis-rotated signing certs. The classic outage; also a security risk if an SP is lenient about accepting new keys.
• Mismatched logout expectations. Assuming “log out” is global when only front-channel best-effort is configured, leaving live sessions on shared machines.
• Default or shared client secrets in OIDC clients, or redirect-URI wildcards that let an attacker capture an authorization code.

None of these are subtle once you know to look for them — which is the point. An SSO review is largely a walk down this list for every federation you operate.

Recap

Single Sign-On is one of identity’s best trades — when you respect what it concentrates.

1. SSO reuses one authentication across many apps via a central IdP, resting on a master IdP session that mints independent SP sessions.
2. It comes in three flavors — Web SSO (SAML/OIDC SaaS), Enterprise SSO (Kerberos/AD, agents, legacy), and Social SSO (log in with a consumer IdP).
3. Its benefits align UX and security: fewer passwords, centralized MFA/policy, and — the budget-winner — one-switch offboarding.
4. Its core risk is concentration: breaking the chain at the IdP breaks everything downstream, so the IdP must be your most-hardened, tier-0 system.
5. Single Logout is the neglected half — genuinely hard because SP sessions are independent — so design with short sessions, back-channel logout, step-up, and server-side revocation rather than trusting a perfect logout.

Three questions to test yourself

1. Explain, using the two-session model, why clicking “log out” in one SSO app can leave you still logged in to another. What two mechanisms reduce that exposure?
2. Your company federates 60 SaaS apps to one IdP. A board member asks “aren’t we putting all our eggs in one basket?” Give the honest answer: what does SSO concentrate, and what four controls make that concentration acceptable?
3. Compare Social SSO and Web SSO for a consumer fintech app. Which would you offer, what dependency does each create, and what native fallback do you keep?

Hands-on exercises

1. Trace a real SSO flow. Log in to any site with “Sign in with Google,” using your browser dev-tools network tab. Identify the redirect to the IdP, the returned token/assertion, and the moment the app creates its own session cookie. Sketch the sequence.
2. Inspect the two sessions. After a Web SSO login, use dev-tools to list cookies for the IdP domain and for the app domain. Note that they are separate — that separation is why SLO is hard.
3. Audit an SLO claim. Pick a SaaS product’s documentation and determine whether it supports SAML SLO or OIDC Back-Channel Logout, and whether it’s front- or back-channel. Write one sentence on what would happen to that app’s session if the IdP logout signal failed to reach it.