Hack the HydraCómo decodificar un JWT
Un JWT son tres cadenas base64url unidas por puntos: cabecera, payload y firma. Para decodificarlo, divide por los puntos y decodifica en base64url las dos primeras partes; cada una es un objeto JSON. No hace falta ninguna clave, porque un JWT firmado no está cifrado. La decodificación no demuestra nada: solo verificar la firma con el secreto o la clave pública del emisor, y comprobar exp, nbf, iss y aud, garantiza que el token es auténtico y sigue siendo válido.
¿Qué contiene un JWT?
Tomemos el token de ejemplo público de la documentación de JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
La primera parte se decodifica como {"alg":"HS256","typ":"JWT"}: el token está firmado con HMAC-SHA256. La segunda da {"sub":"1234567890","name":"John Doe","iat":1516239022}. La tercera es la firma, bytes en bruto codificados en base64url, que solo tiene sentido para quien tiene la clave.
¿Cuáles son las claims habituales?
| Claim | Significado |
|---|---|
| sub | Sujeto: a quién se refiere el token, normalmente un id de usuario |
| iss | Emisor: quién creó el token |
| aud | Audiencia: qué API debe aceptarlo |
| iat | Emitido en, segundos Unix (1516239022 = 18/01/2018 01:30:22 UTC) |
| nbf | No válido antes de, segundos Unix |
| exp | Caduca en, segundos Unix |
| scope / roles | Permisos (el nombre varía según el proveedor) |
¿Cómo depurar un error 401?
Una llamada a la API que funcionaba ayer devuelve 401. Decodifica el token de la cabecera Authorization y revisa en orden:
- exp: ¿ya pasó? La mayoría de los tokens de acceso duran de 5 a 60 minutos; es la causa más frecuente.
- aud: ¿nombra la API a la que llamas?
- iss: ¿viene del entorno correcto? Un token de staging falla en producción.
- scope o roles: ¿está el permiso necesario?
- Desfase de reloj: si iat o nbf está unos segundos en el futuro, los relojes no coinciden.
Si todo parece correcto, el problema probablemente es la firma, por ejemplo una clave de firma renovada.
¿Qué errores de seguridad hay que evitar?
- Confiar en un payload decodificado. Cualquiera puede crear un token con "role": "admin"; solo una firma verificada hace fiables los claims.
- Aceptar alg "none" o dejar que el token elija el algoritmo. Fija el algoritmo esperado en el servidor.
- Poner secretos en el payload. Un JWT firmado lo puede leer cualquiera que lo tenga.
- Pegar un token activo en una herramienta en línea que lo envía a un servidor. El decodificador JWT de este sitio decodifica en tu navegador, sin enviar nada.
¿Cómo decodificar un JWT? Tres formas
- En el navegador: pega el token en el decodificador JWT. Muestra la cabecera y el payload como JSON, convierte iat, nbf y exp en fechas e indica si el token ha caducado. No se envía nada.
- En una terminal: toma la parte central, pasa de base64url a base64 (cambia - por + y _ por /, añade el relleno =), ejecuta
base64 -dy pasa el resultado ajq. - En el código: la mayoría de las bibliotecas JWT tienen una función de decodificación sin verificación, solo para depurar. En producción, llama a la función de verificación con la clave, el algoritmo, el emisor y la audiencia esperados.
FAQ
¿Necesito el secreto para decodificar un JWT?
No. La cabecera y el payload solo están codificados en base64url. El secreto o la clave pública sirven para verificar la firma, no para leer el contenido.
¿Por qué mi JWT tiene cinco partes?
Es un token cifrado (JWE): su contenido solo se lee con la clave de descifrado.
¿Cómo sé si un JWT ha caducado?
Compara su claim exp, en segundos Unix, con la hora actual. El decodificador JWT de este sitio lo muestra como fecha y marca los tokens caducados.
Actualizado: noviembre de 2026. Los archivos se procesan en su navegador y no se envían a ningún servidor.