What is Single Sign-On?
Single Sign-On (SSO) lets users authenticate once and access multiple applications without logging in again. Instead of managing separate credentials for each application, users authenticate with a central Identity Provider (IdP) that vouches for them across all connected services.
How SSO Works
When a user visits an application (the Service Provider, or SP), the SP checks whether the user has an active session. If not, it redirects the user to the Identity Provider. The IdP authenticates the user (password, MFA, biometrics) and sends a signed assertion back to the SP confirming the user's identity. The SP creates a local session, and the user is in. When the user visits a second application, the IdP already has a session — so no second login is needed.
SAML 2.0
Security Assertion Markup Language is the traditional enterprise SSO protocol. It uses XML-based assertions exchanged between IdP and SP via browser redirects. A typical SAML flow:
1. User visits app.example.com
2. App redirects to idp.company.com/saml/sso
3. IdP authenticates user, creates XML assertion
4. IdP posts signed assertion back to app
5. App validates signature, creates session
SAML assertions are Base64-encoded XML. Use the Base64 Encoder to decode and inspect SAML assertions during debugging.
OpenID Connect (OIDC)
OIDC is the modern alternative to SAML, built on top of OAuth 2.0. It uses JSON instead of XML and is simpler to implement. The IdP returns a JWT (JSON Web Token) containing the user's identity claims. OIDC is the protocol behind "Sign in with Google/Microsoft/GitHub" buttons. The JWT payload is JSON — validate and inspect it with the JSON Formatter.
SAML vs OIDC
SAML is designed for enterprise web applications and uses XML. OIDC is designed for web and mobile applications and uses JSON/JWT. SAML has broader enterprise adoption; OIDC is simpler and better for new applications. Many IdPs support both. Choose SAML when integrating with legacy enterprise systems; choose OIDC for new applications, mobile apps, and SPAs.
Identity Federation
Federation connects multiple identity systems so users from one organisation can access resources in another. For example, a company's employees can access a SaaS application using their corporate credentials. The IdP and SP exchange metadata (certificates, endpoints) to establish trust. Federation is what makes SSO work across organisational boundaries.
Implementation Considerations
Session management is the hardest part of SSO. When a user logs out of one application, should they be logged out of all applications (single logout)? Single logout is complex and often unreliable in practice — many implementations settle for local logout plus session timeouts. Token expiry, refresh tokens, and session synchronisation all need careful design. Generate strong session secrets with the Password Generator.
Security Risks
SSO centralises authentication, which is both a strength and a risk. A compromised IdP gives an attacker access to everything. Mitigations include strong MFA on the IdP, hardware security keys for admin accounts, and monitoring for anomalous login patterns. Token replay attacks are prevented by short-lived tokens, audience validation, and nonce checking.
Choosing an Identity Provider
Major IdPs include Okta, Azure AD (Entra ID), Auth0, Keycloak (open source), and Google Workspace. Evaluate based on protocol support (SAML + OIDC), MFA options, directory integration (LDAP, AD), and pricing. For small teams, Auth0's free tier or Keycloak self-hosted are good starting points. For enterprises, Okta and Azure AD dominate.