Single Sign-On (SSO): An Overview
What problems SSO solves and the difference between same-network and federated scopes.
With Single Sign-On a user authenticates only once and gains access to many applications. Authentication is centralised at an identity provider (also known as IdP), and each application trusts the provider’s assertion rather than having to manage its own identity store.
This solves many problems at once:
- User experience: one login instead of many;
- Security: credentials are only entered at the IdP, never at individual applications;
- Administration: revoking access at the provider propagates to all applications at once;
- Consistency: MFA, password policies and audit logs are enforced in a single place.
Examples:
- Google Account provides access to Gmail, Drive, YouTube and others;
- Okta provides access to Datadog, Superset, Zendesk and others.
We must ask ourselves: do the IdP and the application share the same network?
When all parties are within the same network, the network itself can serve as a security boundary. When a user logs in once, inside that network, that is already proof of identity for every other server on the same network.
This network-locality is an assumption of LDAP, which is in itself both one of its perks (for introducing less complexity) and limitations.
This is the case for when applications and the IdP do not share the same network. They could live on different data centres, could be owned by different companies, etc. Trust has to be gained through different means, so they exchange proof of who they are before any user login ever happens.
Then, upon receiving an assertion, the application sends its login request to the IdP’s specified endpoint, verifies the assertion’s authenticity using the IdP’s public signing key, and decrypts it using its own private key (which would match the public key provided to the IdP).
SAML and OIDC are the two most widely-used standards for implementing SSO across the network boundary.