What Is SSO? Single Sign-On Explained

Single sign-on (SSO) lets a user authenticate once with a single identity provider and gain access to multiple separate applications afterward, without entering credentials again for each one. Instead of every application maintaining its own password database and login form, applications trust one central authority to vouch for who the user is — the user proves their identity once, and every app that trusts that authority accepts the result.

The roles involved

SSO involves two kinds of parties in a trust relationship:

• Identity provider (IdP) — the central service that authenticates the user and issues proof of that authentication. Common examples are corporate directory services and dedicated identity platforms.
• Service provider (SP) — any individual application that relies on the IdP’s word instead of handling login itself. This could be email, an internal wiki, a CRM, or any number of separate tools a user needs during a session.

The IdP and each SP establish a trust relationship ahead of time — typically by exchanging cryptographic keys or a shared configuration — so the SP knows how to verify that a login assertion actually came from the IdP and wasn’t forged.

How the flow works

1. A user tries to access a service provider (say, a wiki) without an active session.
2. The service provider redirects the user to the identity provider instead of showing its own login form.
3. The user authenticates with the IdP — often combined with multi-factor authentication for stronger assurance.
4. The IdP issues a signed assertion or token confirming who the user is, and redirects back to the service provider carrying that proof.
5. The service provider validates the signature, trusts the assertion, and creates its own local session for the user.

If the user then visits a second service provider that trusts the same IdP, the IdP recognizes it already has an active session for that user and skips straight to issuing a new assertion — no password prompt required. That’s the “single” in single sign-on: one authentication event covers every trusting application until the session expires.

The protocols underneath

SSO isn’t a protocol itself — it’s the user-facing pattern that a few different protocols implement. SAML is an older XML-based standard still common in enterprise environments, exchanging signed assertions over browser redirects. OAuth 2.0 combined with OIDC (OpenID Connect) is the more modern approach, where OIDC layers identity on top of OAuth’s authorization framework and typically issues a JWT as the identity token. See OAuth vs OIDC vs SAML for a closer comparison of how these three actually differ. Whichever protocol is in use, the tokens involved are often JWTs in practice, so a tool like our free JWT decoder is useful for inspecting exactly what claims an SSO assertion is carrying.

Why organizations adopt it

• Fewer passwords to manage. Users remember one set of credentials instead of one per application, which reduces password reuse and weak-password risk.
• Centralized deprovisioning. Disabling a departing employee’s account at the IdP immediately cuts off every connected application at once, instead of requiring someone to manually revoke access app by app.
• Consistent policy enforcement. MFA requirements, session timeouts, and conditional access rules can be enforced once, centrally, rather than configured separately in every application.
• Better user experience. One login instead of a dozen reduces friction and the support burden of password resets.

The tradeoffs

SSO concentrates risk as much as it concentrates convenience. If the identity provider is compromised, every connected application is compromised along with it — the IdP becomes the single highest-value target in the whole system, which is why it deserves the strongest zero trust posture and phishing-resistant authentication such as passkeys rather than a plain password. Session and token handling also matter more than usual: a stolen assertion or an overly long-lived session at the IdP effectively grants access everywhere at once, not just to a single app.

Session lifetime and logout

SSO also changes what “logging out” means. A single sign-out at the identity provider can, if implemented, end the session at every connected service provider at once — but that requires each SP to actively check back with the IdP rather than just trusting a token until it naturally expires. In practice, many SSO integrations only implement single sign-on, not single sign-out: a user can end their session at one app while remaining logged into others until each app’s own session or token separately expires. That gap matters most on shared or public devices, where a user might reasonably assume closing one app logged them out everywhere.

Token and assertion lifetimes are a related design choice. A short-lived token forces more frequent round-trips back to the identity provider but limits how long a stolen token remains useful; a long-lived one reduces friction but widens the window an attacker has if a token leaks. This is the same tradeoff JWTs face generally — expiry is a security control, not just a convenience knob — and it applies with extra weight in SSO, where a single leaked assertion can potentially unlock several applications at once rather than just one.

SSO vs per-application login

	Per-application login	Single sign-on
Credentials to manage	One per app	One, centrally
Deprovisioning	Manual, per app	Immediate, centralized
Failure blast radius	Limited to one app	Every connected app
Policy enforcement (MFA, timeouts)	Configured per app	Enforced once, centrally
User friction	A login per app	One login per session

The takeaway

SSO trades a login form in every application for a single trusted identity provider that every application defers to. The user authenticates once; every service provider that trusts the same IdP accepts the resulting assertion without asking for credentials again. That centralization is the whole point — fewer passwords, instant deprovisioning, consistent policy — but it also means the identity provider itself has to be defended harder than any single downstream app, since compromising it compromises everything it’s connected to.