JWT y OAuth: los siete errores de autenticación que abren la puerta sin romper la criptografía
Casi nunca falla la criptografía: falla cómo se valida el token, dónde se guarda y qué confía el flujo OAuth. Los siete patrones de autenticación rota que más encontramos, qué probar y cómo corregir.
El ataque no fuerza el candado: usa la puerta de atrás
Cuando una autenticación con JWT u OAuth cae en un pentest, casi nunca es porque rompimos AES o RSA. Es porque la validación del token tiene un agujero, el flujo confía en un parámetro que el atacante controla, o el token vive en un sitio del que se puede robar. La autenticación rota es el ítem A07 del OWASP Top 10, y es donde un solo fallo se convierte en acceso a la cuenta de cualquier usuario.
Abajo, los siete patrones que más encontramos: qué son, cómo los probamos y qué los corrige.
1. alg: none y variantes
Un JWT indica cómo debe verificarse en su propia cabecera (alg). Bibliotecas antiguas o mal configuradas aceptan alg: none —token sin firma— o no fijan el algoritmo esperado. Prueba: cambiar alg a none, quitar la firma, ver si el backend lo acepta. Corrección: fijar el algoritmo en el servidor (allowlist); nunca leer alg del token para decidir cómo validar.
2. Confusión RS256 → HS256
El servidor usa RS256 (clave pública/privada). El atacante cambia la cabecera a HS256 (simétrico) y firma el token usando la clave pública —que es, por definición, pública— como si fuera el secreto HMAC. Las bibliotecas que eligen el verificador según el alg del token caen en esto. Corrección: verificador estrictamente atado al algoritmo esperado.
3. Secreto HMAC débil o filtrado
HS256 con un secreto de secret, changeme, el nombre de la empresa, o un secreto filtrado en un repositorio público. Con el secreto, el atacante forja cualquier token: se hace admin en una línea. Prueba: ataque de diccionario offline sobre la firma. Corrección: secreto aleatorio de alta entropía, fuera del código, rotable.
4. Claims no validados
La firma es correcta, pero el backend no valida exp (expiración), aud (audiencia) ni iss (emisor). Un token expirado sigue válido; un token emitido para otro servicio se acepta. Prueba: reutilizar un token expirado, usar un token de otro entorno/servicio. Corrección: validar siempre exp, nbf, aud, iss; rechazar por defecto.
5. redirect_uri laxo en OAuth
El corazón de muchos account takeover vía SSO. Si el servidor de autorización compara redirect_uri por prefijo o permite subdominios/paths arbitrarios, el atacante desvía el code o el token a un dominio que controla. Variantes: un open redirect encadenado en el flujo, state ausente (CSRF en el login), PKCE no exigido en clientes públicos. Prueba: manipular redirect_uri, quitar state, interceptar el code. Corrección: allowlist exacta de redirect_uri, state obligatorio, PKCE en SPA y móvil.
6. Token en el sitio equivocado
Un JWT en localStorage lo lee cualquier XSS, y entonces un solo XSS se convierte en robo de sesión persistente. Token en logs, en la URL (el referer se filtra), en la caché de un CDN. Corrección: cookies HttpOnly, Secure, SameSite; nunca un token de sesión en localStorage; nunca un token en la query string.
7. Sin revocación y sesión eterna
Un JWT es stateless: una vez emitido, vale hasta que expira. Si exp es largo y no hay lista de revocación ni refresh token rotado, un token robado funciona horas o días, y cambiar la contraseña no desconecta al atacante. Corrección: exp corto + refresh token rotado y revocable; invalidar sesiones al cambiar la contraseña y al cerrar sesión.
Por qué el escáner no lo detecta
Casi todos exigen manipular el token y entender el flujo: dos contextos, dos cuentas, un proxy interceptando el handshake OAuth. Un escáner ve un login que funciona y sigue. Es prueba manual, guiada por el OWASP WSTG (sección de autenticación) y las buenas prácticas de OAuth 2.0 / OIDC.
Qué pedir en el pentest
Pide cobertura explícita de: manipulación de alg, confusión de algoritmo, fuerza bruta offline del secreto, validación de claims, todo el flujo OAuth/OIDC (incluidos redirect_uri, state, PKCE), almacenamiento del token y ciclo de vida de la sesión. Y pide el encadenamiento hasta el impacto: "forjé un token de admin" vale más que "no se valida exp".
Cómo lo prueba Pentest Machine
En los pentests de web y API tratamos la autenticación como superficie de primera clase: manipulación de JWT, flujos OAuth/OIDC completos, SSO, almacenamiento y sesión, con PoC reproducible para cada fallo y el camino hasta el account takeover cuando existe. Informe ejecutivo + técnico y retest incluidos. Si usas SSO o emites JWT a clientes, esta es la prueba que separa "parece seguro" de "es seguro".