Un JSON Web Token son tres bloques Base64url unidos por puntos: cabecera, payload y firma. Esta herramienta los separa y te muestra qué contienen. No comprueba la firma, y la omisión es deliberada: el motivo merece dos minutos de tu tiempo.
Descodificar no es verificar
Son operaciones completamente distintas, y confundirlas provoca incidentes de seguridad. Descodificar no requiere nada: la cabecera y el payload están codificados en Base64url, no cifrados, así que cualquiera que tenga el token lee todos sus claims. Verificar requiere la clave de firma y responde a otra pregunta: ¿lo emitió realmente quien dice, y lo ha alterado alguien desde entonces?
Una herramienta que lee un token no demuestra nada sobre su validez. Si pegas aquí un token caducado verás igualmente su contenido perfectamente representado. Que la descodificación funcione solo te dice que la cadena está bien formada, nada más.
Por qué esta herramienta se niega a verificar firmas
Muchos sitios sobre JWT ofrecen una casilla para tu secreto de firma junto al token. Piensa en lo que te están pidiendo. Con HS256, el secreto es la misma clave que acuña tokens válidos: entrégalo a una página web y quien la gestione podrá falsificar cualquier token para tu sistema. No hay forma de verificar una firma simétrica sin ceder también la capacidad de crear firmas.
Así que esta herramienta no te lo pide, y harías bien en desconfiar de las que sí. Verifica las firmas en tu propio código, en tu propio entorno de ejecución, con la clave cargada desde tu propio almacén de secretos. Una clave de firma pertenece exactamente a dos sitios: el servicio que emite tokens y el que los comprueba.
Los claims con los que se tropieza
Las marcas de tiempo son las culpables habituales. El RFC 7519 define exp, iat y nbf como NumericDate: segundos desde la época Unix. Date.now() de JavaScript devuelve milisegundos. Pasar uno donde se espera el otro es el fallo de JWT más común que existe: un token que caduca en 1970, o uno que sigue válido los próximos cincuenta mil años. Si un exp descodificado muestra una fecha en un pasado remoto o un futuro absurdo, has encontrado un factor de 1000.
La otra sorpresa frecuente es nbf, "not before". Un token puede estar perfectamente firmado, sin caducar, y aun así ser rechazado porque todavía no es válido: suele ser síntoma de desfase de relojes entre la máquina emisora y la validadora, más que de algo mal en el token.
El campo alg es una instrucción, no una descripción
La cabecera lleva un claim "alg" que nombra el algoritmo de firma, y la vulnerabilidad clásica de JWT es una biblioteca que se fía de él. Si un validador lee alg del token y verifica en consecuencia, un atacante puede poner alg a "none", quitar la firma y entrar: el propio token le dijo al validador que no comprobara.
El ataque emparentado cambia RS256 por HS256. Con RS256 el token se firma con una clave privada y se verifica con la pública. Un validador ingenuo que lea alg como HS256 usará esa clave pública como secreto HMAC, y la clave pública es, por definición, pública. Ambos ataques son antiguos y las bibliotecas mantenidas hoy rechazan valores de alg que quien llama no haya permitido explícitamente. Si ves un token cuya cabecera dice "none", o estás probando algo o estás viendo un ataque.
Qué no poner en un payload
Como el payload lo puede leer cualquiera que tenga el token, no es lugar para nada privado. Ni notas internas sobre el usuario, ni lógica de permisos que preferirías no tener que explicar, ni datos personales más allá de los que el token necesita para su trabajo. La firma impide la modificación, no la lectura: una distinción que ha dejado en evidencia a muchos equipos que dieron por hecho que un token firmado era un token sellado.
Preguntas frecuentes
¿Se envía mi token a un servidor?
No. Esta herramienta está marcada como "client": la separación y la descodificación ocurren en la pestaña de tu navegador y el token nunca sale de tu máquina. Pero merece la pena cuestionar el hábito en general: un JWT es una credencial viva. Si has pegado un token de producción en cualquier sitio web, este incluido, lo más prudente es asumir que debe rotarse.
¿Puedo comprobar si este token es válido?
Aquí no, ni en ningún sitio que no gestiones tú: mira la sección de arriba. Lo que sí puedes comprobar a simple vista es si el token ha caducado, ya que exp está ahí en el payload descodificado. Eso cubre el motivo más común por el que un token deja de funcionar, sin que ninguna clave cambie de manos.
¿Por qué la caducidad aparece como una fecha de 1970?
Porque se está leyendo una marca de tiempo en milisegundos como si fuera en segundos. Divide entre 1000 y la fecha tendrá sentido. Lo que haya producido el token está usando Date.now() donde el RFC 7519 espera Math.floor(Date.now() / 1000).
¿Puedo editar un token y volver a firmarlo aquí?
No. Cambiar un solo carácter del payload invalida la firma, y producir una nueva válida requiere la clave de firma, que —como se ha visto arriba— no es algo que se pegue en una página web. Editar tokens es algo que se hace en tu propia suite de pruebas con una clave de prueba.
El token tiene puntos pero no se descodifica. ¿Por qué?
La mayoría de las veces no es un JWT. Los tokens cifrados (JWE) tienen cinco segmentos en vez de tres, y su payload es realmente ilegible sin la clave. La otra causa común es el truncamiento: los tokens son largos y los recortan los formateadores de registros, el ancho del terminal y las celdas de las hojas de cálculo. Si el segmento central termina de golpe, probablemente te faltan caracteres en lugar de tener un token mal formado.