SSO

Single Sign-On

Updated September 30, 20263 min read

In short

SSO lets a user sign in once with a central identity provider and then access many separate applications without entering credentials again.

What is SSO?

SSO, or single sign-on, lets people use one account and one login to reach many applications. Instead of each app keeping its own usernames and passwords, they all trust a central identity provider (IdP), the service that stores accounts and checks credentials. Once you sign in to the IdP, other apps accept that login, so you can open email, chat, and internal tools without typing your password again.

Under the hood, SSO relies on standard protocols. When you visit an app, called the service provider, it redirects you to the IdP; after you authenticate, the IdP sends back a signed assertion, either a SAML response or an OpenID Connect ID token, that proves who you are. The app verifies the signature, creates its own session, and never sees your password. OpenID Connect is built on OAuth 2.0 and is the common choice for modern web and mobile apps, while SAML is widespread in older enterprise software.

A good analogy is a wristband at a music festival: you show your ticket and ID once at the entrance, and staff at each stage simply check the wristband. SSO is used by companies for employee tools, by schools and universities, and in consumer apps that let you sign in with an account you already have.

SSO is often confused with OAuth and with password managers. OAuth is about granting an app permission to access resources, while SSO is about logging in, and OpenID Connect adds that login layer on top of OAuth. A password manager still logs you in to each site separately with different passwords, whereas SSO relies on one identity provider, which becomes a high-value target that must be protected with strong multi-factor authentication.

Key takeaways

One login at a central identity provider gives access to many applications.
Apps receive a signed SAML assertion or OpenID Connect ID token, not the user's password.
OpenID Connect is built on OAuth 2.0; SAML is common in enterprise software.
Central accounts make it easy to disable a departing user's access everywhere at once.
The identity provider is a high-value target and needs strong MFA.

Example

Starting an OpenID Connect login (Express)javascript

// Step 1: redirect the user to the identity provider to log in
const params = new URLSearchParams({
  client_id: "my-app",
  response_type: "code",
  scope: "openid email profile",
  redirect_uri: "https://app.example.com/callback",
  state: crypto.randomUUID(), // checked on return to prevent CSRF
});
res.redirect(`https://idp.example.com/authorize?${params}`);

// Step 2: at /callback, exchange the code for an ID token, verify its
// signature, and start the app's own session. Production apps also use
// PKCE and a nonce; a well-tested OpenID Connect library handles these steps.

Readers ask

Is SSO the same as OAuth?

Not exactly. OAuth 2.0 is a protocol for granting an app limited access to resources, while SSO is the experience of logging in once for many apps. SSO is commonly implemented with OpenID Connect, which adds authentication on top of OAuth 2.0, or with SAML.

Is SSO secure?

SSO can improve security because users manage one strong credential, MFA is enforced in one place, and access can be revoked centrally. The trade-off is that a compromised SSO account opens many doors, so the identity provider must be protected with phishing-resistant MFA.

What is the difference between SAML and OpenID Connect?

Both let an identity provider tell an app who the user is. SAML uses XML assertions and is common in older enterprise tools, while OpenID Connect uses JSON-based JWT ID tokens and is the usual choice for modern web and mobile apps.

Often compared

OAuth vs SSOOAuth lets an app reach a user's data on another service without their password, while SSO is one login for many apps, built on SAML or OpenID Connect.

SSO