OAuth / SAML / SSO

El inicio de sesión federado (“Entrar con Google/Microsoft”) delega la autenticación a un proveedor de identidad (IdP). Los fallos no suelen estar en el protocolo sino en cómo la aplicación lo implementa: validaciones laxas que permiten robar el código/token de la víctima y tomar su cuenta.

sequenceDiagram
    participant U as Usuario
    participant C as Cliente (app)
    participant AS as Servidor de autorización
    U->>C: inicia sesión con el proveedor
    C-->>U: redirect al AS (client_id, redirect_uri, scope)
    U->>AS: se autentica y consiente
    AS-->>U: redirect a redirect_uri con code
    U->>C: entrega el code
    C->>AS: intercambia code por token (client_secret)
    AS-->>C: access_token

Modelo de amenaza

Toma de cuenta (ATO) del usuario en la app cliente, robo de tokens de acceso, y acceso a los recursos que el scope conceda (correo, perfil, APIs).

Anatomía

OAuth 2.0 (autorización) define roles: resource owner (usuario), client (la app), authorization server (IdP). El flujo recomendado es authorization code + PKCE; el implicit está obsoleto. Parámetros clave: redirect_uri, state, scope, code. OIDC añade autenticación con un id_token (JWT). SAML hace lo equivalente con aserciones XML firmadas.

Red Team

Ataques OAuth/OIDC

• redirect_uri débil: si la validación no es exacta (permite subdominios, paths, redirect_uri abierto), redirige el code/token a tu dominio → robo del code.
• state ausente/no validado: login CSRF → forzar a la víctima a iniciar sesión con tu cuenta, o vincular su cuenta a la tuya.
• Fuga del code: por Referer, en logs, o por un open redirect encadenado.
• Implicit flow: el token viaja en el fragmento → fuga más fácil.
• Account linking / pre-ATO: registrar la cuenta de la víctima antes de que use SSO.
• SSRF vía discovery/jwks_uri manipulable; confusión de JWT en el id_token (ver ficha de JWT).

Ataques SAML

• Firma no validada o validada mal → aceptar aserciones forjadas.
• XML Signature Wrapping (XSW): reestructurar el XML para que se valide una parte y se procese otra.
• Comment/NameID injection y XXE en el parser de SAML.

Herramientas

Burp Suite (+EsPReSSO), SAML Raider (manipular/firmar aserciones), y tu propio servidor para capturar codes/tokens.

Impacto y encadenamiento

ATO directo, acceso a APIs con el token robado, y pivote a todo lo que el SSO protege.

Blue Team

Detección

• Peticiones de autorización con redirect_uri fuera de la lista registrada.
• Ausencia de state/PKCE; id_token con iss/aud/nonce incorrectos.
• Aserciones SAML con firmas inválidas o estructura anómala (XSW).

Telemetría y fuentes

Logs del IdP y del cliente OAuth, WAF, y validación de tokens/aserciones.

Hardening

1. redirect_uri con coincidencia exacta (lista blanca completa, sin comodines).
2. state obligatorio + PKCE en todos los flujos; usar authorization code, no implicit.
3. Validar iss, aud, nonce, exp del id_token; jwks_uri fijo y de confianza.
4. SAML: validar firma estrictamente (esquema + canonicalización), deshabilitar DTD (anti-XXE), y protegerse de XSW con librerías robustas.

Respuesta

Invalidar sesiones/tokens, corregir validaciones, y revisar vinculaciones de cuentas sospechosas.

CVEs y casos reales

• XML Signature Wrapping en SAML — clase de fallo que afectó a múltiples SSO empresariales y SDKs a lo largo de los años.
• Misconfiguraciones de “Sign in with…” — redirect_uri/state laxos han dado lugar a numerosas ATO reportadas en bug bounty.

CVEs concretos en NVD (https://nvd.nist.gov/vuln/search) y GitHub Advisories (https://github.com/advisories).

Checklist de prueba

• Validación de redirect_uri (subdominio, path, open redirect encadenado).
• state presente y validado; PKCE en uso.
• Fuga de code/token por Referer/logs/fragmento.
• id_token: iss/aud/nonce/firma (ver JWT).
• SAML: firma, XSW, XXE en el parser.

Referencias

• PortSwigger — OAuth 2.0 authentication vulnerabilities
• HackTricks — OAuth to Account Takeover
• OWASP — SAML Security Cheat Sheet
• SAML Raider
• oauth.net (OAuth 2.0)