Decodificador JWT
Pega un JSON Web Token y lee lo que dice: quién lo emitió, para quién es, qué permite y cuándo deja de funcionar. El token nunca sale de esta página.
El token se decodifica dentro de esta página mientras escribes o pegas: no se nos envía, no se guarda y no se añade a la dirección. Se ignoran un Bearer inicial y los saltos de línea.
Trata un token real de producción como una contraseña: hasta que caduque, quien lo tenga puede actuar como tú, así que evita pegarlo en cualquier sitio web que no controles.
Tres trozos de texto unidos por puntos
Una vez que has iniciado sesión en un sitio web, el servidor tiene que reconocerte en la siguiente petición. Una forma habitual de hacerlo es entregar a tu navegador una nota breve y firmada que dice “este es el usuario 48213, con permiso para leer pedidos, hasta las 3:15 pm”. Esa nota es un JSON Web Token, o JWT.
Un JWT parece una cadena larga y aleatoria, pero siempre tiene la misma forma, header.payload.signature.
- La cabecera (header) es un pequeño objeto JSON que nombra el algoritmo de firma (
alg) y a menudo la clave que se usó (kid). - El payload es un objeto JSON de claims, que son afirmaciones como
sub(quién),aud(para qué servicio) yexp(hasta cuándo). - La firma (signature) es un sello calculado a partir de los dos primeros trozos y una clave.
La cabecera y el payload se escriben en Base64URL, una manera de deletrear bytes con letras, dígitos, - y _ para que sobrevivan al viaje por una dirección o una cabecera HTTP. Por eso casi todos los tokens empiezan por eyJ, que es cómo sale {" en esa codificación.
Codificado no es cifrado
Base64URL es una forma de deletrear. No cierra nada con llave, y volver a convertirlo en texto no requiere ninguna clave, que es todo lo que hace esta página. Así que un JWT firmado no oculta absolutamente nada. Si el payload contiene un correo electrónico, un rol o un ID interno, cualquiera que se haga con el token puede leerlo, sea una extensión del navegador, el registro de un proxy o una captura de pantalla.
Lo que te da la firma es integridad. Cambia un solo carácter del payload y el sello ya no coincide, así que el servidor rechaza el token. La gente aún puede leerlo. Solo que no puede reescribirlo.
Un token con cinco partes es un objeto distinto, un JWE, y su contenido sí está cifrado. Esta herramienta muestra su cabecera, explica las cinco partes y se detiene ahí. Nunca pide una clave.
Qué lee esta página y qué señala
El decodificador quita un Bearer inicial, los espacios y los saltos de línea, divide el token e imprime la cabecera y el payload como JSON con formato. Después repasa los claims uno por uno. Las tres fechas, exp, nbf (not before, no antes de) e iat (issued at, emitido en), son números de segundos desde el 1 de enero de 1970. Las ves en tu zona horaria y en UTC, con una cuenta en vivo como “válido durante 12 minutos más”.
| Hallazgo | Por qué importa |
|---|---|
| Caducado, o todavía no válido | Se compara con el reloj de tu dispositivo. Un servidor correcto rechaza el token. |
Sin claim exp | El token funciona para siempre, salvo que el servidor lleve una lista de tokens revocados. |
| Vida útil de más de 30 días | Un token robado sigue siendo útil durante todo ese tiempo. |
alg es none | El token no está firmado. Cualquiera puede escribir uno. |
| Fechas en milisegundos | Un valor 1000 veces mayor significa que, para un receptor estricto, el token nunca caduca. |
| Datos personales, o un campo con nombre de secreto | Todo el que tenga el token puede leerlo. |
jku, x5u o jwk en la cabecera | El token apunta a su propia clave, y un falsificador también puede hacerlo. |
También recibes unas palabras sobre el algoritmo. HS256 usa un secreto compartido para firmar y para comprobar. RS256, ES256 y EdDSA usan un par de claves, donde una clave privada firma y una clave pública comprueba, de modo que los servicios que solo comprueban tokens no pueden crearlos.
Lo que decodificar no puede decirte
Esta página no comprueba la firma. Para eso haría falta el secreto o la clave pública del emisor, y una página que te pide tu secreto de firma es una página que hay que cerrar. Por eso, aquí un token falsificado y uno auténtico se ven igual. Lee el resultado como “esto es lo que el token afirma”, nunca como “este token es válido”.
Por la misma razón, “no caducado” solo significa que exp es posterior al reloj de tu dispositivo. Puede que el servidor haya revocado el token hace una hora.
Si estás escribiendo la parte receptora, las comprobaciones que cuentan se hacen en tu código. Acepta solo los algoritmos que esperas, verifica la firma con una clave en la que ya confías y después compara iss, aud y exp con lo que esperas. Usa una biblioteca mantenida y nunca tomes decisiones según el alg que pide el token.
Un token activo es una credencial
Hasta que caduca, un token bearer funciona para quien lo presente. Si pegas un token de producción en un sitio web, se lo has entregado a ese sitio web, a menos que la decodificación ocurra en tu navegador. Aquí ocurre. Ninguna petición lleva el token, no se escribe en la barra de direcciones y no se guarda en el almacenamiento del navegador. No tienes que fiarte de nuestra palabra: mira la pestaña de red de las herramientas de desarrollo, o carga la página y desconéctate antes de pegar.
Aun así, el hábito más seguro es depurar con tokens de una cuenta de prueba o con tokens caducados. Si un token real acaba en un chat, en un ticket o en un registro público, cierra sesión en todas partes o pide al emisor que lo revoque.
Preguntas frecuentes
¿Es seguro pegar un JWT en un decodificador en línea?
Solo si el decodificador funciona en tu navegador y no envía nada. Este divide y decodifica el token en local, no hace ninguna petición con él y no guarda nada. Con tokens de producción, uno caducado o de una cuenta de prueba sigue siendo la mejor opción.
¿Se puede decodificar un JWT sin la clave secreta?
Sí. La cabecera y el payload son texto Base64URL que cualquiera puede volver a convertir en JSON. Solo necesitas el secreto o la clave para comprobar la firma, o para crear un token que un servidor acepte.
¿Qué significan exp, iat y nbf en un JWT?
exp es el momento en que el token deja de aceptarse, iat el momento en que se emitió y nbf el momento en que empieza a aceptarse. Los tres son números de segundos desde el 1 de enero de 1970 (UTC), no milisegundos.
¿Por qué mi token empieza por eyJ?
La cabecera es un objeto JSON, así que empieza por {", y esos caracteres siempre salen como eyJ en Base64. El payload empieza igual por la misma razón.
¿Cuál es la diferencia entre HS256 y RS256?
HS256 firma y comprueba con un único secreto compartido, así que cualquier servicio capaz de comprobar un token también podría falsificarlo. RS256 firma con una clave privada y comprueba con una clave pública. Así muchos servicios pueden comprobar tokens mientras que solo el emisor puede crearlos.
¿Por qué es peligroso un token con alg none?
No lleva firma, así que cualquiera puede editar lo que contiene. Un servidor que lo acepta deja que la gente elija su propio ID de usuario o su rol. Los receptores tienen que listar los algoritmos que aceptan y rechazar todo lo demás.