What is Single Sign-On (SSO)?
An authentication setup where one login with one account gives a user access to many separate applications.
Definition
Single sign-on (SSO) is an authentication arrangement in which a user signs in once, with one account and its authenticators, and then gets into multiple independent applications without logging in to each one separately. NIST's digital identity guidelines (SP 800-63-4) define it as an authentication process by which one account and its authenticators are used to access multiple applications, and note that it is generally implemented with a federation protocol. In that model a central identity provider (IdP) authenticates the user and issues a signed statement about them, and each application, called a service provider or relying party, trusts that statement instead of checking a password itself. The two protocols most SSO deployments use are SAML 2.0, where the IdP sends an XML assertion through the browser to the service provider, and OpenID Connect, an identity layer on top of OAuth 2.0 in which the IdP issues an ID Token, a JWT containing claims about how and when the user authenticated. Self-hosted identity providers such as Keycloak and Authentik play the IdP role.
When to Use Single Sign-On (SSO)
SSO is about authentication (who the user is); what they may do in each app is still authorization, usually driven by groups or roles passed in the assertion or token. Plan logout as well as login: SAML defines a Single Logout profile, but sessions already created inside each application may outlive the IdP session unless the app supports logout propagation. Because one account now unlocks everything, SSO is normally paired with multi-factor authentication at the IdP. Apps that speak neither SAML nor OpenID Connect are typically put behind a reverse proxy that checks the IdP session for them.
Single Sign-On (SSO) in Practice
- An employee signs in to the company identity provider in the morning; opening GitLab, Grafana and the HR system later redirects briefly to the IdP and back, with no further password prompt.
- A SaaS app offers 'Sign in with SAML SSO' for enterprise customers: the customer's IdP sends a signed SAML assertion through the browser and the app creates a session from it.
- A homelab puts Authentik or Keycloak in front of self-hosted dashboards over OpenID Connect, so one account and one MFA prompt cover all of them.
Common Mistakes
- Treating OAuth 2.0 access tokens as proof of login. OAuth is for delegated authorization; use OpenID Connect's ID Token (or SAML) for authentication.
- Not validating assertions and tokens properly: signature, issuer, audience and expiry must all be checked by the application.
- Leaving local password logins enabled in each app after rolling out SSO, which keeps a bypass around the IdP's MFA and offboarding.
- Assuming logging out of one app logs the user out everywhere; without single logout support, other app sessions stay valid.