Single sign-on (SSO) is an authentication method that lets a user log in once and then access multiple connected applications without re-entering credentials. One authenticated session, established with an identity provider, is trusted across many services.

SSO is one of those capabilities that’s invisible when it works and infuriating when it doesn’t. Behind the convenience sits a well-defined trust mechanism built on open standards.

How SSO works

When a user opens an application, the app redirects them to the identity provider (IdP). The IdP authenticates the user (increasingly with passkeys or risk-based methods rather than a password) and issues a signed token using a standard like OpenID Connect or SAML. Each application trusts that token instead of asking for the password again. The credential lives in exactly one place; the apps only ever see a token that says "this user is authenticated."

The benefits

• For customers: fewer logins, less password fatigue, and fewer resets and abandoned sessions, which shows up directly in engagement and conversion.
• For security teams: one central place to enforce MFA, passwordless, and risk-based policy, plus far fewer credentials scattered across apps to be phished or leaked.
• For architects: a standards-based way to connect many applications to one identity source, reducing per-app authentication code.

The security trade-off to respect

Centralizing authentication concentrates value. If SSO becomes the master key to everything, then compromising that one login compromises everything behind it. That’s not a reason to avoid SSO (the alternative (reused passwords across dozens of apps) is worse) but it raises the bar on protecting the central login. Phishing-resistant methods like passkeys and FIDO2, backed by risk-based step-up for sensitive actions, are what make SSO safe at scale rather than a single point of catastrophic failure.

SSO in customer contexts

For consumers, SSO often shows up as social login ("continue with…") or as a unified account across a brand’s properties. The strategic version is a first-party SSO across all of a company’s digital channels, so a customer signs in once and is recognized everywhere, which also removes silos and gives fraud teams a consistent view.

The protocols behind SSO

SSO isn’t one technology but a pattern implemented through federation standards. SAML, the XML-based veteran, still dominates enterprise and B2B SSO. OAuth 2.0 is an authorization framework for delegated access to resources. OpenID Connect (OIDC), built on top of OAuth 2.0, adds the identity layer and is now the default for modern web and mobile SSO. In every case the mechanism is the same: the application redirects to the IdP, the IdP authenticates and returns a signed token, and the app trusts the token rather than re-collecting the credential. Knowing which protocol applies matters mostly to architects; to the user, it’s just "one login, many apps."

SSO risks and how to mitigate them

The convenience of SSO concentrates risk: one login unlocks many systems, so if that login is phished or a session is stolen, the blast radius is large. The mitigations are well understood. Protect the central login with phishing-resistant authentication (passkeys/FIDO2) so it can’t be relayed through a fake page. Apply risk-based step-up for sensitive actions even within an SSO session, so a single authentication isn’t a permanent all-access pass. Manage session lifetimes and re-verification carefully, and watch for session hijacking with continuous, signal-based evaluation. Done this way, SSO’s centralization becomes a security advantage (one hardened, well-monitored control point) rather than a single point of catastrophic failure.

SSO in the customer world vs. the workforce

SSO means slightly different things depending on who’s logging in. In the workforce, SSO usually connects employees to a portfolio of internal and SaaS apps through the corporate IdP, and the priorities are governance, provisioning, and audit. In the customer world, SSO is about giving one person a single identity across a brand’s own properties (the web app, the mobile app, the loyalty program, the call center) plus optional social login as an entry point. The customer version weights experience and fraud much more heavily: the sign-in has to be fast and low-friction to protect conversion, and it has to be watched for account takeover because customer accounts are attacked constantly. Same core pattern of "authenticate once, access many," but tuned to very different goals, which is another reason customer SSO belongs in a purpose-built CIAM platform rather than a repurposed workforce tool.

Frequently asked questions

How is SSO different from a password manager?

A password manager stores many passwords; SSO removes the need for separate logins by centralizing authentication with one trusted provider.

Is SSO secure?

It’s more secure than reused passwords across apps, but the central login must be protected with strong, phishing-resistant authentication.

What protocols enable SSO?

Primarily OpenID Connect (OIDC), OAuth 2.0, and SAML.

What is social login?

A consumer form of SSO where users authenticate with an existing account from another provider.

Related: Identity Provider (IdP) · Identity Federation · OpenID Connect (OIDC) · SAML · Passwordless Authentication · Passkeys