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:
- Lax
redirect_uri: if the authorization server accepts an unregisteredredirect_uri(or does a prefix/substring match), thecodeortokenis delivered to an attacker domain.
GET /authorize?client_id=web&response_type=code&redirect_uri=https://attacker.tld/cb&scope=openid&state=xyz- Missing
state: without that parameter (or without checking it) the flow is vulnerable to login CSRF (forcing the victim to link an attacker's account). codetheft via open redirect on the legitimate domain, or a token leaked in theRefererof the implicit flow.
SAML. The crux is the XML signature:
- Unsigned assertions accepted, or a signature that is never verified.
- XML Signature Wrapping (XSW): a legitimately signed assertion is wrapped and a second, unsigned one with a different
NameIDis added, which the application reads by mistake.
<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.