Single sign-on (SSO)

Two technical families share the name. Enterprise or network SSO is dominated by Kerberos, which originated in MIT's Project Athena; version 5 is specified in RFC 4120. At logon the client obtains a ticket-granting ticket from the key distribution centre (the AS exchange), then presents it to request a service ticket for each service (the TGS exchange), so the password is used once and services only ever see tickets. Active Directory implements this, and browsers extend it to intranet web apps through SPNEGO and the HTTP Negotiate scheme (RFC 4559). Web SSO instead uses federation protocols: the application redirects the browser to an identity provider, which authenticates the user once and then returns a SAML assertion or an OpenID Connect ID token to each application in turn. On Entra-joined Windows devices, a Primary Refresh Token extends SSO to native and browser apps.

The mechanics explain most operational surprises. After the first login the IdP sets its own session cookie. When the user opens a second application, that application redirects to the IdP, the IdP sees its session and issues a new assertion without prompting (in OIDC the same silent path can be requested explicitly with prompt=none), and the application creates its own local session. There are therefore at least two session layers with independent lifetimes. Disabling a user at the IdP blocks new sign-ins immediately but does not end existing application sessions or revoke OAuth refresh tokens unless the applications support back-channel logout, continuous access evaluation or short sessions. Single logout in SAML and OIDC exists but is fragile across many applications.

Security effects run both ways. SSO removes password prompts from dozens of applications, shrinks the phishing surface to one well-known login page, centralises MFA, conditional access and sign-in logging, and makes deprovisioning a single action. In return the IdP account becomes a master key, so it needs phishing-resistant MFA and careful monitoring. Benefits erode when applications keep local fallback logins, API tokens or break-glass passwords outside SSO; those should be inventoried and disabled or protected. Applications that need stronger assurance for specific actions can request step-up through SAML's requested authentication context or OIDC's acr_values and max_age.

Several things are often mislabelled as SSO. Password synchronisation or LDAP bind against a central directory is "same sign-on": users type the same password everywhere and each application still sees it. Password vaulting or form-fill tools replay stored passwords. Federation is the cross-organisation case of SSO, where the IdP and the application belong to different trust domains and the trust is governed by metadata and agreements.