the_open_door
coffee
ESEN
← Back to index

OAuth / SAML Abuse

Federated login flows (OAuth 2.0 / OpenID Connect and SAML) delegate authentication to an identity provider. Their bugs are rarely in the cryptography: they are in validations the application skips, and they usually grant access to other people's accounts or full account takeover.

OAuth / OIDC. The classic vectors:

GET /authorize?client_id=web&response_type=code&redirect_uri=https://attacker.tld/cb&scope=openid&state=xyz

SAML. The crux is the XML signature:

<saml:Assertion><saml:Subject><saml:NameID>admin@company.com</saml:NameID></saml:Subject></saml:Assertion>

A NameID we swap for an administrator's, when the signature does not cover that node, is direct access.

How to detect it. In OAuth, the signature is an authorization whose redirect_uri is not in the client's registered list, or code exchanges from a domain other than expected. In SAML, responses with assertions lacking a valid signature or with duplicate nodes (a sign of wrapping). Watch for missing state and a NameID that does not match the user authenticated at the IdP.

Defence. Register and exactly match the redirect_uri (no wildcards), require and verify state, and use PKCE; in SAML, always verify the signature, ensure it covers the whole assertion, and reject responses with multiple Assertion/Subject nodes. The resulting tokens are validated as in JWT and tokens.