Single Sign-On (SSO)

Single Sign-On (SSO) lets a user authenticate once with a central identity provider and then use many applications and systems without entering credentials again. It removes password sprawl for users and gives the organization one place to enforce strong authentication and to withdraw access, at the price of making that provider and its session a single point of failure and a single target. SSO is an architecture rather than a protocol, delivered today mostly through OpenID Connect or SAML 2.0.

Modern SSO implementations use OpenID Connect (OIDC) for authentication, which is built on top of the OAuth authorization framework, and older applications still use SAML 2.0. Where SSO spans organizations rather than applications within one, OpenID Federation establishes which providers may participate without configuring each pair of parties individually. The identity provider itself is usually a Cloud IAM service, and Identity Orchestration sits in front of it where several providers have to be combined. The protocols are settled. What decides whether SSO makes an organization safer is the set of decisions around them: how long a session lives and how it ends, how well the one login is protected, what happens to the applications that cannot federate, and what the organization does on the day the provider is unavailable.

Sessions, and How They End

An SSO login creates more than one session. The identity provider keeps its own, usually a cookie in its domain, and every application the user opens from it sets another. Behind the applications there may be access and refresh tokens for their APIs as well. Each has its own lifetime, and the user experiences the longest of them: an application that keeps its session for a month ignores whatever the provider's policy says about reauthentication. The provider session is therefore a policy decision that has to be made for the whole estate. It sets a maximum lifetime and an inactivity timeout, and it forces a fresh login for sensitive actions, which applications request with max_age or through Step Up Authentication Challenge. NIST SP 800-63B gives upper bounds for reauthentication at each assurance level and is a defensible anchor for that policy. Application sessions should not outlast it.

Single logout is the reverse problem. Ending the provider session does nothing to the cookies applications have already set, so logout has to reach every application separately. SAML single logout does this by passing the browser from application to application, and one application that fails to answer breaks the chain. OpenID Connect's front-channel variant depends on third-party cookies, which several browser engines block by default and others restrict. Back-channel logout, in which the provider calls each application's server directly, is the mechanism that still works, and the OIDC article compares the options. Even that ends sessions and leaves tokens valid until they expire. An organization that promises users "log out everywhere" should test the promise against its most important applications before making it.

One Session, Every Application

The benefit and the risk of SSO are the same property. One login grants access to every connected application, so one stolen provider session does too. Phishing has adapted to this. Adversary-in-the-middle kits relay the victim's login to the real identity provider, pass any one-time code or push approval through, and keep the session cookie that results. A second factor that the user can be tricked into completing on the attacker's page does not stop them.

Two technologies address the two halves of that attack. Passkeys and other FIDO2 credentials are bound to the provider's domain, so a login on a look-alike site fails before any session exists. Because SSO puts every login through one provider, this is where phishing-resistant authentication is cheapest to introduce: the change is made once, at the provider, and every federated application benefits without being modified. Device Bound Session Credentials protect the session after the login by binding the cookie to a key on the user's device, which makes a cookie stolen by malware worthless elsewhere. Neither helps with an application that still accepts a local password next to SSO. Local logins have to be disabled once federation works, or the phishing-resistant path is only an option the attacker ignores.

When a session is compromised anyway, the damage depends on how quickly every application hears about it. The Shared Signals Framework carries session-revoked and credential-change events from the provider to applications that subscribe to them, so that revocation takes effect at the next request instead of at the next token expiry. Identity Threat Detection and Response watches the provider for the anomalies that should trigger that revocation.

SSO is also where Zero Trust attaches to users. The provider verifies the user and the device at login and evaluates policy there, and continuous evaluation with shared signals extends that decision over the life of the session.

Applications That Cannot Federate

Every estate has applications that speak neither OpenID Connect nor SAML: older commercial software, appliances, thick clients and internal tools nobody maintains. There are four answers, in order of preference. The application can be replaced or upgraded to a version that federates, which is the only one that removes the problem. It can be placed behind a reverse proxy or access gateway that authenticates the user against the provider and passes the identity on in a header, which works when the application trusts the header and nobody can reach it except through the proxy. It can authenticate against the directory over Lightweight Directory Access Protocol (LDAP), which gives users one password but not one login, since the password is typed into every application and every application can capture it. Or its credentials can be vaulted and filled in on the user's behalf, which hides the password from the user but leaves it in existence.

The last two options keep passwords in use, and with them the risk SSO was meant to remove. The list of non-federated applications, with the option chosen for each and a date for its replacement, is one of the more useful documents an SSO programme produces, because it shows where the organization's strong authentication does not reach.

Accounts Are Not Sessions

SSO controls who can log in. It does not control which accounts exist inside the applications. When an employee leaves, disabling them at the provider stops new logins, but the account in each application remains, along with any session that is still open, any API token the user created and any local credential that bypasses SSO. Just-in-time provisioning, in which an application creates an account at the first federated login, makes this worse over time: accounts are created automatically and never removed.

Deprovisioning is what closes the gap, and System for Cross-domain Identity Management (SCIM) is the protocol that carries it. The provider or the identity governance system pushes joiners, movers and leavers to every application that supports it. Auditors test leaver processes by sampling departed employees and checking the applications, not the provider, so "supports SSO and SCIM" belongs in the procurement criteria for any new application.

When the Identity Provider Is Down

Centralizing login centralizes failure. If the provider is unavailable, misconfigured by a faulty policy change, or locked by an attacker who has taken over its administration, no federated application can be reached, including the consoles needed to fix the problem. This is an organizational question more than a technical one, and it needs an answer before the incident.

The answer has three parts. The first is break-glass accounts: a small number of emergency administrator accounts that authenticate without the provider or bypass its conditional access policies, protected by hardware security keys or by credentials held in a privileged password vault, excluded from routine use, and alerting on every login. They can only be relied on if they are tested, so they belong in regular incident exercises. The second is the provider's own configuration, which has become the most valuable target in the estate: administrative roles held without standing privileges, and policy changes tracked and checked for drift through Identity Security Posture Management. The third is knowing which applications must remain reachable without the provider, such as the systems used to respond to incidents, and how they are reached when it fails.