What is Single Sign-On (SSO)?
SSO lets a user authenticate through one identity service and then access several relying applications without entering credentials at each application. It reuses a central authentication session or federation assertion, not one shared password. SAML, OpenID Connect, and Kerberos can support SSO. LDAP is a directory protocol, and OAuth alone is an authorization protocol.
Why it matters
SSO reduces repeated credential entry and gives an organization a central place for authentication policy. It can also make access removal and authentication monitoring more consistent across applications.
How it works
- An application or access proxy redirects the user to the configured identity provider.
- The identity provider authenticates the user and returns a federation response for the relying application or proxy.
- A central session or later federation responses let the user open other participating applications without entering credentials again.
Example
A user signs in to the company identity provider once and then opens Grafana and Jenkins through Pomerium without a second password prompt.
Pomerium boundary
Pomerium authenticates users through an OIDC identity provider and can provide SSO for applications behind Pomerium, including applications that do not implement SSO. Pomerium then applies route policy before it proxies each HTTP request.
Limits and non-claims
- SSO authenticates a user but does not by itself authorize every action in each application.
- Logout behavior depends on the identity provider, relying applications, and local session handling.
- An identity-provider outage or compromised central session can affect several connected applications.
Evaluation checklist
- Does each relying party validate the issuer, client, redirect, correlation values, and returned identity?
- How do joiner, mover, leaver, reauthentication, and logout events change active sessions?
- Can a local login, weak recovery path, or identity-provider compromise expand the SSO blast radius?
