OAuth / SAML Abuse

Los flujos de inicio de sesión federado (OAuth 2.0 / OpenID Connect y SAML) delegan la autenticación en un proveedor de identidad. Sus fallos rara vez están en la criptografía: están en validaciones que la aplicación se salta, y suelen dar acceso a cuentas ajenas o account takeover.

OAuth / OIDC. Los vectores clásicos:

• redirect_uri laxo: si el servidor de autorización acepta un redirect_uri no registrado (o hace prefix/substring match), el code o el token se entregan a un dominio del atacante.

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

• Falta de state: sin ese parámetro (o sin comprobarlo) el flujo es vulnerable a CSRF de login (forzar el enlace de una cuenta del atacante).
• Robo de code por open redirect en el dominio legítimo, o token filtrado en el Referer del flujo implícito.

SAML. El nudo está en la firma XML:

• Aserciones sin firmar aceptadas, o firma que no se verifica.
• XML Signature Wrapping (XSW): se envuelve una aserción firmada legítima y se añade otra sin firmar con un NameID distinto que la aplicación lee por error.

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

Un NameID que cambiamos por el de un administrador, si la firma no cubre ese nodo, es acceso directo.

Cómo detectarlo. En OAuth, la firma es una autorización cuyo redirect_uri no está en la lista registrada del cliente, o intercambios de code desde un dominio distinto al esperado. En SAML, las respuestas con aserciones sin firma válida o con nodos duplicados (indicio de wrapping). Vigilar state ausentes y NameID que no casa con el usuario autenticado en el IdP.

Defensa. Registrar y casar exactamente el redirect_uri (sin comodines), exigir y verificar state y usar PKCE; en SAML, verificar siempre la firma, que cubra la aserción completa, y rechazar aserciones con múltiples Assertion/Subject. Los tokens resultantes se validan como en JWT y tokens.