SSO misconfiguration

What it means

SSO misconfiguration is a mistake in how your app trusts a single sign-on provider. The sign-in protocols are sound, but they only work if your app checks the right things: who issued the statement, who it was meant for, whether it is signed and whether it has expired.

When one of those checks is missing or too loose, the app accepts a statement that was never meant for it. The sign-in page still works for honest users, which is why the flaw can sit unnoticed for years. That makes it a quiet kind of flaw, and one that tends to be found only by someone deliberately sending the wrong input.

Why it matters

The result is usually account takeover, and often of the most powerful accounts. A statement from a different company's tenant, a different application or an unverified email address can be enough to be treated as your administrator. Because sign-in sits at the front door of everything, the effect spreads to every part of the product.

It also hits the customers you most want. Large buyers connect their own identity provider, and a flaw in how you handle that connection can mix up one customer's people with another's. That is a data breach in a product that was only meant to make sign-in easier.

How it shows up

Common causes are accepting tokens from any tenant of a shared identity provider, not checking the audience, linking accounts by email address without confirming ownership, and loose redirect address rules. Also check that the app refuses unsigned statements and that a customer's own setup cannot name someone else's domain.

Look at the callback in your code and at the settings in both systems. Test with a statement issued for another application or tenant, and with a changed email claim. See OpenID Connect and SAML for the checks each protocol expects.