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

Sara’s morning, and her last day

Sara López is a nurse at a hospital that connects all its applications to one identity provider. At 8:00 she opens the scheduling app, which sends her to the identity provider, where she signs in with a passkey on her managed laptop. At 8:05 she opens the patient records system and it lets her straight in, without asking for anything. To her it feels as if the app already knew her. Three weeks later, when she moves to another hospital, IT disables a single identity, and that afternoon she can’t get into any of the dozens of applications she used.

That’s single sign-on (SSO), and both halves of the story matter. The previous articles were about proving identity: factors, MFA, biometrics. SSO is about what happens with that proof once you have it, reusing one authentication across many applications so the user doesn’t type credentials at every door. It’s one of the most valuable patterns in identity because it improves usability and security at the same time, which is rare. Done carelessly, it concentrates risk so tightly that one stolen session opens a company’s entire application estate.

SSO speaks the protocols from the previous module, SAML and OIDC on top of OAuth. Here we assume you know what an assertion and an ID token are, and focus on the architecture and trade-offs of tying many apps to one sign-in.

What SSO actually is

In single sign-on, a user authenticates once with a central identity provider (IdP) and then reaches several independent service providers, or relying parties, without authenticating again. The applications don’t check a password themselves; they trust a signed assertion from the IdP saying “this is Sara, authenticated at this time, at this level of assurance.”

The mechanism rests on two kinds of session that people often mix up. The IdP session is the master session created when you first sign in, living at the identity provider, usually as a cookie on the IdP’s domain. The application sessions are separate sessions that each app creates for you after it accepts the IdP’s assertion, independent of each other and managed locally. That distinction explains everything that follows. SSO is easy to reason about at sign-in, where one master session produces many application sessions, and hard at sign-out, precisely because those application 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, a second app
  U->>I: Auth request (IdP session already exists)
  I-->>U: Assertion immediately, no new sign-in

Three kinds of SSO

“SSO” names a goal, not a single technology. Three architectures dominate, and confusing them leads to muddled design conversations.

Web SSO is what most people mean today: browser-based applications connected to one identity provider over SAML or OIDC. One corporate sign-in through Entra ID, Okta, or Ping opens dozens of SaaS apps; one campus sign-in opens every university system. The IdP holds the session, and each application trades a redirect for an assertion. It’s where most modern effort goes, and it’s what the diagram above shows.

Enterprise SSO extends single sign-on beyond the browser to desktop and legacy applications inside a network, thick clients and on-premises systems that never spoke SAML. It has historically come from Kerberos and Active Directory, where you sign in to Windows, get a ticket, and domain-joined apps accept it silently, or from an enterprise SSO agent that fills stored credentials into apps that only understand a username and password. It’s the older, messier cousin of web SSO, and very much alive in large companies with legacy systems.

Social SSO is “Sign in with Google, Apple, or Facebook,” where a consumer identity provider acts as the IdP for third-party sites over OIDC. It removes sign-up friction and hands password management to a provider the user already trusts. The trade-offs differ from the workforce case: you inherit that provider’s account-security decisions, you depend on them, and you have to think about what happens when a user loses access to that social account. Offering more than one option, plus a native fallback, is the usual answer.

Who starts the flow

The diagram showed a flow started by the service provider: the user begins at the application, which sends them to the IdP. There’s a second pattern worth knowing, because it behaves, and fails, differently.

In the SP-initiated flow, the user lands on the app first through a bookmark or a deep link, finds no session, is sent to the IdP to authenticate, and comes back. It’s the common, recommended flow, and because the app started the exchange, it can check that the assertion it receives answers its own request. In the IdP-initiated flow, the user starts at the IdP, in a portal or app launcher, clicks a tile, and the IdP sends an unsolicited assertion straight to the app. It’s convenient but riskier: the app receives an assertion it never asked for and can’t tie it to a pending request, which historically opened the door to replayed assertions and login CSRF. OIDC largely discourages unsolicited assertions for that reason. Prefer the SP-initiated flow, and if you must support the IdP-initiated one, as many enterprise portals do, harden it with strict assertion validation, tight time windows, and replay protection. Knowing which flow you’re in explains a lot of odd SSO incidents.

How the trust is set up

SSO only works because each application has a trust relationship with the IdP set up in advance. That trust is concrete configuration, and it’s where a surprising number of outages and vulnerabilities live.

In SAML, the IdP and the service provider exchange metadata: entity IDs, endpoint URLs, and public signing certificates, which tell each side where to send messages and how to check signatures. OIDC does the same through a discovery document (.well-known/openid-configuration) and client registration. The IdP signs assertions with its private key, and the application checks them with the IdP’s public certificate. If that certificate expires, a classic cause of outages, or is swapped without coordination, every sign-in breaks at once. If an application is careless about which key it trusts, forged assertions become possible, which is the essence of the Golden SAML attack: an attacker who steals the IdP’s signing key can mint valid assertions for anyone. Treat that key as a crown jewel, keep it in an HSM, restrict access tightly, and watch for unusual issuance.

The assertion carries claims such as email, groups, and roles, and the application maps them to its own users and permissions. Get the mapping wrong, by trusting an unverified email or over-trusting a group attribute, and you have an authorization bug riding on a perfectly working sign-in. Many applications also create a local account on the first SSO sign-in from the assertion’s attributes, which is just-in-time provisioning. It pairs with SCIM for the full lifecycle: SSO handles authentication, and SCIM handles creating and removing the account itself. People often mix the two up, but SSO signing a user in doesn’t by itself remove their account when they leave. That’s SCIM’s job.

Why nearly everyone adopts it

SSO is unusual in that its usability case and its security case point the same way. The visible win is one sign-in instead of dozens, which is what gets it funded. Behind it, people who manage one strong credential instead of forty stop reusing passwords, stop writing them on sticky notes, and stop picking variations of Company2026!, and the individual apps no longer hold passwords at all, so there’s nothing in them to leak. Security policy becomes central: MFA, conditional access, and risk-based rules are enforced once at the IdP and every connected app inherits them, so a new phishing-resistant requirement protects the whole estate at once. Authentication events converge on one system, giving logs, anomaly detection, and ITDR a single valuable stream to watch.

The lifecycle benefit is the strongest of all. Onboarding grants access through one identity, and offboarding, as Sara’s last day showed, is a single switch: disable the central identity and the leaver loses every connected app at once, instead of everyone hoping that forty separate accounts get cleaned up, which they never all do. If you have to justify SSO to a skeptical budget owner, lead with that rather than with convenience. It’s a compliance and breach-prevention story auditors like, and it’s exactly where estates without SSO fail, leaving orphaned accounts scattered across dozens of SaaS tools.

What SSO isn’t

SSO gets confused with three neighbors. It isn’t a password manager. A password manager still gives each app its own password; it just stores and fills them in for you, so every app keeps a credential that can leak on its own, and there’s no central point to switch off at offboarding. SSO removes the per-app password by making apps trust the IdP. A password manager is a way of coping without SSO; SSO is the structural fix. It isn’t “same sign-on” either. Some setups sync the same username and password to many apps through a directory so it feels unified, but each app still authenticates independently against its own copy. Real SSO has one authentication and one session that the others trust. And it isn’t authorization. Signing in through the IdP proves who you are; it doesn’t decide what you may do inside each app. That’s the subject of the modules that follow, and every app still has to enforce its own permissions on top of a successful SSO sign-in.

When an app can’t do SSO

Real estates are never fully federated, and the gaps are where risk collects. Some apps don’t support SAML or OIDC at all, 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 are exactly the accounts that escape the benefits above: they keep their own passwords, get missed at offboarding, and don’t inherit your central MFA. Push vendors for standards support and budget for the SSO tier on anything sensitive. Where a real integration is impossible, fall back to a password manager or a privileged access vault with per-app MFA and a deliberate offboarding runbook. And keep an inventory of the exceptions, so you know exactly which accounts sit outside the centrally governed core. The goal isn’t perfection; it’s knowing where your coverage ends.

The core risk: concentration

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, and practitioners talk about its blast radius. An attacker no longer needs to phish forty apps; they phish the one sign-in that opens all of them, which makes the IdP the most valuable credential target in the organization. A stolen IdP session, through session hijacking, a stolen token, or malware on the device, gives the attacker SSO into every connected app without authenticating again, the same smoothness that helps Sara at 8:05 now helping the attacker. If the IdP goes down, nobody can sign in to anything connected to it, which makes it a business-critical dependency and not only a security one. And a single bad federation setting, a lax validation, a stale signing certificate, an overly broad trust, can expose many applications at once. Golden SAML and several high-profile breaches involving identity providers are this risk come true: once the identity layer falls, moving into everything federated is nearly free.

SSO doesn’t remove risk; it relocates and concentrates it on the identity provider. That’s a good trade only if the IdP is defended accordingly. Require phishing-resistant MFA, FIDO2 or passkeys, for all access and especially for administrators. Apply conditional access on device, location, and risk. Keep IdP sessions short and require re-authentication for sensitive actions. Validate assertions and signatures strictly. And monitor continuously, feeding ITDR. Treat the IdP as tier-0 infrastructure, like a domain controller. None of this means giving up on SSO, because the alternative, dozens of independent passwords, is worse. It means hardening the IdP out of proportion, checking again at the application for valuable actions through step-up, and not trusting the SSO session forever, which is the continuous-verification mindset of Zero Trust.

How long the master session should live

One lever is underused: the lifetime of the IdP’s master session decides how often users face a real sign-in and, more importantly, how long a stolen master session stays useful. Make it weeks of “stay signed in” and the smooth SSO experience becomes a smooth experience for attackers too. Make it too short and people re-authenticate constantly, which erodes the whole benefit.

The modern answer is a risk-based lifetime rather than one fixed number, tying back to the adaptive ideas from the factors article. A low-risk session on a managed, compliant device can last comfortably, while one on an unmanaged device, from a new location, or reaching for sensitive resources gets a shorter leash and more frequent checks. Combine a sensible absolute lifetime with step-up at the application for high-value actions, and you get the convenience of a long SSO session without giving it unlimited power. At 12:30, when Sara tries to export a batch of patient records, the records system doesn’t rely on her sign-in from four hours earlier; it asks her to confirm with her passkey right then. The session was valid, but the action deserved fresh proof.

Single logout: the hard, neglected half

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

Remember the two kinds of session: ending the IdP session doesn’t automatically end the application sessions it produced. Each application has to be told and has to comply. The IdP has to remember every application the user opened during the master session and reach each one, bookkeeping that’s easy to get wrong. Front-channel logout sends the browser through a chain of per-app logout URLs, often in hidden iframes, and it’s fragile: it breaks when a tab is already closed, when third-party cookies are blocked, which browsers increasingly do by default, or when any app in the chain is slow or down. Back-channel logout has the IdP call each application’s logout endpoint server to server, through OIDC Back-Channel Logout or SAML SLO. It’s sturdier, but it only works if every application implements and honors the callback, and many don’t. Logout is only as complete as its weakest participant. One application that ignores the signal, and the person who thinks they’ve signed out everywhere still has an open door, which on a shared or public computer is a real exposure.

Good practice leans on short session lifetimes, so that a missed logout heals itself quickly, which in practice often does more than trying to make SLO perfect. It uses back-channel logout as the main mechanism where the protocol and the applications support it, with front-channel as best-effort cleanup. It requires re-authentication for sensitive actions, so a lingering session can’t do damage on its own. And it’s clear with users about what “sign out” actually did, because signing out of one app and out of the whole estate are different acts. When Sara signs out at 17:00 on a shared workstation, the IdP session ends and the applications wired for back-channel logout end theirs; any that aren’t keep a live session, which is exactly why the workstation also enforces a short idle timeout. Assume single logout is partial and design around it, using short sessions, step-up, and server-side revocation, which the session management article covers.

Common misconfigurations

Most SSO incidents aren’t exotic protocol breaks; they’re configuration mistakes, and the recurring ones make a good review checklist. Weak assertion validation is the first: not checking the signature, the audience, the intended recipient, the time window, or replay, any of which turns a stolen or forged assertion into a valid sign-in. Next comes trusting attributes too broadly. Matching accounts on an unverified email claim lets an attacker who controls a matching address hijack the mapping, and trusting a group or role claim without limiting which IdP may assert it is the same mistake. Then there’s an IdP-initiated flow left wide open, accepting unsolicited assertions without replay protection or tight timing, and an IdP with no MFA of its own, which recreates the blast-radius risk in its worst form, one phished password opening everything. Expired or badly rotated signing certificates cause the classic outage and become a security risk if an application is lenient about accepting new keys. Teams assume “sign out” is global when only best-effort front-channel logout is configured. And OIDC clients ship with default or shared secrets, or with wildcard redirect URIs that let an attacker capture an authorization code. None of these is subtle once you know to look, which is the point: an SSO review is largely a walk down this list for every federation you run.

Recap

Single sign-on is one of identity’s best trades, as long as you respect what it concentrates. It reuses one authentication across many apps through a central IdP, with a master IdP session that produces independent application sessions. It comes in three kinds: web SSO over SAML and OIDC, enterprise SSO through Kerberos, Active Directory, agents, and legacy integration, and social SSO through a consumer identity provider. Its benefits align usability and security: fewer passwords, central MFA and policy, and, the one that wins budgets, one-switch offboarding. Its core risk is concentration, so the IdP has to be your most hardened, tier-0 system. And single logout is the neglected half, hard because application sessions are independent, so design with short sessions, back-channel logout, step-up, and server-side revocation instead of trusting a perfect logout.

Three questions to test yourself

1. Using the two kinds of session, explain why clicking “sign out” in one SSO app can leave you still signed in to another. Which two mechanisms reduce that exposure?
2. Your company connects 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 which 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 which native fallback would you keep?

Hands-on exercises

1. Trace a real SSO flow. Sign in to any site with “Sign in with Google” while watching the network tab in your browser’s developer tools. Identify the redirect to the IdP, the returned token or assertion, and the moment the app creates its own session cookie. Sketch the sequence.
2. Inspect the two sessions. After a web SSO sign-in, use the developer tools to list the cookies for the IdP’s domain and for the app’s domain. Notice that they’re separate; that separation is why single logout is hard.
3. Audit a single logout claim. Pick a SaaS product’s documentation and find out whether it supports SAML SLO or OIDC Back-Channel Logout, and whether it’s front-channel or back-channel. Write one sentence on what would happen to that app’s session if the IdP’s logout signal didn’t reach it.