Identity · Federation
Single Sign On
One authentication event, evaluated by a central identity provider, granting access to many applications through issued tokens or assertions.
FoundationalUpdated 2026-09-01
Overview
SSO moves authentication out of individual applications and into an identity provider. The application becomes a relying party that trusts signed assertions, so password handling, MFA and policy are implemented once rather than dozens of times.
SSO improves both usability and security, but it concentrates risk: the identity provider becomes the highest value system in the estate, and its availability determines whether anyone can work.
How it works
- 01SAML exchanges XML assertions, typically via browser POST, between an identity provider and a service provider.
- 02OpenID Connect layers identity on OAuth 2.0, issuing JWT ID tokens plus access tokens for API authorisation.
- 03Provisioning is usually paired via SCIM so accounts and group memberships are created, updated and, critically, deprovisioned automatically.
Why it matters
- It eliminates dozens of independent password stores, each of which is a breach candidate.
- It creates one place to enforce MFA, device compliance and session policy.
- It creates one authoritative audit trail of application access.
Security considerations
- Validate assertion signatures, audience and expiry; never accept unsigned SAML responses.
- Protect identity provider signing keys and monitor for federation trust changes, adding a rogue trusted domain or signing certificate is a stealthy persistence technique.
- Enforce SCIM based deprovisioning; SSO without lifecycle automation leaves orphaned entitlements inside applications.
Common misconfigurations
- Local application accounts left enabled alongside SSO, bypassing policy.
- Wildcard or overly broad reply URLs in application registrations.
- No plan for identity provider outage, resulting in an estate wide work stoppage.