Engineering glossary
Single Sign-On(SSO)
Single sign-on (SSO) is an identity pattern that lets a user authenticate through a central identity provider and access multiple connected applications without signing in separately to each one.
In plain language
SSO centralizes the sign-in experience, but each application still decides what an authenticated user may do. Authentication federation and application authorization are separate responsibilities.
Why it matters to a business
- Reduces separate credentials and repeated sign-in steps
- Centralizes identity policy and account disablement
- Can simplify access onboarding and offboarding across connected applications
How it works
- 1The application redirects the user to a trusted identity provider.
- 2The provider authenticates the user and returns a signed assertion or token.
- 3The application validates issuer, audience, signature, time, and other required claims.
- 4The application maps the identity to a local account and applies its own permissions.
Common use cases
- Workforce access through a corporate identity provider
- Customer access across a suite of products
- Partner portals using federated organizational identity
Important implementation decisions
- OpenID Connect or SAML protocol fit
- Account linking and just-in-time provisioning
- Session lifetime, logout, and recovery
- User lifecycle and emergency access
Common mistakes and misconceptions
- Treating SSO as authorization
- Trusting an email address without validating token claims
- Ignoring deprovisioning and local-session termination
Limitations and trade-offs
SSO reduces credential sprawl but makes identity-provider availability and configuration more consequential.
Federation does not eliminate application-specific accounts, permissions, or audit requirements.
Authoritative references
Need to apply this concept to a real system?
A focused technical discussion can identify the decisions and constraints that matter before implementation.