SSO
In identity management, SSO is single sign-on: one authentication event grants access to many applications, so the user proves who they are once and each application accepts an assertion instead of its own login. It is convenient, it removes a large number of passwords, and it concentrates risk into one place.
How it works
An identity provider authenticates the user and issues a signed assertion to each service provider that trusts it. The application validates the signature, reads the claims, and creates its own local session. Two protocols carry this in practice: SAML, which is XML-based and still dominant in enterprise software, and OpenID Connect, which is built on OAuth 2.0 and dominant in newer and mobile applications.
The detail that matters operationally is that there are two sessions, not one. The session at the identity provider decides whether you will be challenged again; the session inside each application is independent of it and has its own lifetime.
What goes wrong
That second session is the recurring finding. Removing a user at the identity provider stops new assertions being issued and does nothing to the sessions already created inside each application, so a revoked user keeps working until each local session expires. During an incident, when speed is the whole point, this is the difference between containment and the appearance of containment.
The second issue is blast radius. Compromise of the identity provider is compromise of everything behind it, and the routes we use are rarely a flaw in the protocol: an administrator without a phishing-resistant credential, a trust relationship added for a supplier, a signing certificate stored where an application team can read it, or the ability to register a new application and grant it permissions. The provider therefore deserves the controls of a domain controller, and is frequently administered like a business application.
The third is what stays outside. Every estate has systems that do not support federation, and they end up on local credentials with no central visibility, which is where password spraying goes first.
Where this shows up in an audit
We test the revocation path explicitly, because it is the control clients most often believe they have: disable the account, then continue using an application session established beforehand and record how long it survives. We also review who can administer the provider, register applications and modify trust, and we enumerate what is not federated. The finding is usually about the seams rather than the protocol. This is part of how we assess the identity platform behind your applications.