Single sign-on (SSO) lets a user authenticate once and gain access to multiple applications during that session, without logging in separately to each one. One identity provider verifies the user and issues a token that connected applications trust, so the credential itself is never shared with every app it touches.
What is single sign-on (SSO)?
SSO solves a specific, everyday problem: nobody wants to log in five times to do one task. A user signs in once at a central identity provider, and every application in that session trusts the result instead of asking for credentials again. It's built for convenience and consolidation, not for proving who someone is beyond that first check. That distinction matters, and we'll come back to it when we compare SSO to MFA below.
How SSO works
SSO runs on a trust relationship between two parties: the identity provider (IdP), which authenticates the user, and the service provider (SP), which is the application the user actually wants to reach. When a user tries to open an application, the SP doesn't ask for a password itself. It redirects the user to the IdP. If the user already has an active session there, the IdP issues a token or assertion confirming who they are, and the SP accepts it without another login prompt. If there's no active session, the user authenticates at the IdP first, and every subsequent app in that session gets the same free pass.
Two protocols carry most of this traffic today. SAML, standardized by OASIS, uses XML-based assertions and has been the backbone of enterprise SSO for two decades, particularly for workforce and browser-based access into corporate applications. OpenID Connect (OIDC), built as an identity layer on top of OAuth 2.0 and standardized as ISO/IEC 26131, uses lighter JSON tokens and fits modern web and mobile apps more naturally. Both do the same essential job: they let an application trust an authentication event it didn't perform itself.
| SAML | OIDC | |
|---|---|---|
| Token format | XML assertions | JSON web tokens |
| Typical fit | Legacy enterprise apps, browser-based workforce access | Modern web, mobile, and API-driven applications |
| Built on | Its own protocol, purpose-built for authentication | OAuth 2.0, with an identity layer added on top |
| Common weak point | Verbose configuration, harder to debug | Requires care distinguishing ID tokens from access tokens |
If you're deciding between the two for a customer identity program, the practical differences are covered in more depth in what OIDC is and why you'd use it for CIAM.
Types of SSO
SSO shows up in two broad shapes. The first is SSO within a single organization's own suite of applications, sometimes just called enterprise or workforce SSO, where one company owns every app and the IdP and SPs sit inside the same trust boundary. The second is federated SSO, where the identity provider and the applications belong to different organizations entirely, and trust is established through a formal federation agreement and shared protocol. This is the real answer to "SSO vs federated identity": SSO is the user experience of one login working everywhere, and federation is the mechanism that makes that possible across organizational boundaries rather than inside one. Every federated setup is a form of SSO, but not every SSO setup requires federation. A company signing employees into its own internal tools doesn't need federation. A retailer letting customers use a bank-issued digital ID to log in does.
Customer SSO, the flavor most relevant to CIAM, usually means one login working across a brand's own family of apps and sites, and sometimes across partner properties too. It's a fundamentally different problem from workforce SSO because the population is unpredictable, the stakes are conversion and trust rather than internal productivity, and the applications often span multiple brands or regions rather than one internal network. For more on how that shapes CIAM as a discipline, see what CIAM is and how CIAM differs from workforce IAM.
SSO vs MFA
SSO and MFA answer different questions, and confusing them is one of the more common mistakes in identity planning. SSO answers "does this user need to log in again for this next application." MFA answers "how confident are we that this login really belongs to this person." One is about reducing the number of authentication events. The other is about strengthening each one. They are not substitutes, and treating SSO as a security control on its own is a mistake. A single weak login protected by nothing but a password, then trusted across ten applications, is worse than ten separate weak logins, because one compromise now grants everything at once. That's exactly why SSO deployments should pair the initial authentication with MFA or adaptive, risk-based checks, so the one moment that grants broad access is the moment that gets the most scrutiny.
SSO vs social login
Social login, where a user signs into a site using an existing Google, Apple, or similar account, is actually a form of federated SSO. The third-party provider acts as the IdP, the site the user is trying to reach acts as the SP, and the same token-based trust relationship applies. What makes social login distinct is who runs the identity provider: a consumer platform the user already has an account with, rather than an enterprise IdP the organization controls. That's convenient for registration and lowers the number of new passwords in the world, but it also means the organization is depending on an external provider's uptime, policies, and data practices. The trade-offs are worth understanding before leaning on it as a primary sign-in method, and we've covered them in detail in the pros and cons of social login providers.
Why SSO matters for customer experience and security
Every extra login screen is a place a customer can give up. Password fatigue is real, and when someone has to create yet another username and password just to check an order status, some of them simply won't finish. SSO removes that friction by making one authenticated session carry across every app or brand property a customer needs to touch, which shows up directly in fewer abandoned sign-ins and fewer support tickets tied to forgotten credentials.
On the security side, SSO centralizes the moment where policy gets enforced. Instead of ten different applications each deciding independently how to handle a login, one identity provider applies consistent rules, logs every authentication event, and gives security teams a single place to look when something looks wrong. That centralization is also what makes adaptive access controls practical: risk signals can be evaluated once, at the point of login, rather than reimplemented app by app.
What to look for in an SSO solution
- Open standard support. SAML and OIDC should both be first-class options, not an afterthought bolted onto a proprietary session model. Standards support is what lets you connect new applications and partners without custom integration work every time.
- Adaptive access built in, not bolted on. The login that grants access everywhere is the login worth scrutinizing hardest. Look for risk-based step-up and step-down decisions applied at that single point.
- Session management across brands and apps. If your organization runs multiple brands or product lines, check whether sessions, timeouts, and logout actually propagate consistently, or whether each app tracks its own state.
- Extensibility for B2B and partner access. Customer SSO often needs to extend to partners, suppliers, or resellers with their own identity systems. Confirm the platform supports federation into external IdPs, not just its own directory.
- Readiness for non-human and AI agent access. As AI agents start acting on behalf of customers or staff, the same authentication and consent model that governs human SSO needs to extend to agent identities, with the same auditability. Identity orchestration is what makes it possible to design these journeys without rebuilding the login flow for every new access pattern.
If you're comparing platforms, our glossary has definitions for the related terms below, and our CIAM overview covers where SSO fits into the broader identity picture.
Frequently asked questions
Does SSO make an account less secure since one login opens everything?
It shifts risk rather than removing it, which is why SSO is almost always paired with strong authentication (MFA, passkeys) and adaptive access on the initial login.
What's the difference between SSO for customers and SSO for employees?
The underlying protocols (OIDC, SAML) are the same; the difference is scale and UX expectations, which is the same IAM-versus-CIAM distinction described above.
Do I need OAuth or OIDC to build SSO?
OIDC is the typical foundation, since it's built specifically to answer "who logged in" across connected applications.
Does SSO make an account less secure since one login opens everything?
It shifts risk rather than removing it, which is why SSO is almost always paired with strong authentication (MFA, passkeys) and adaptive access on the initial login.
What's the difference between SSO for customers and SSO for employees?
The underlying protocols (OIDC, SAML) are the same. The difference is scale and UX expectations, which is the same IAM-versus-CIAM distinction described above.
Related terms
- Federated identity (above)
- OIDC (adjacent)
- Adaptive access (adjacent)
- MFA (below)
See also
Entries that come up in the same conversation as single sign-on (SSO).
.avif)