Decodificador JWT

Un JSON Web Token (JWT) está formado por tres segmentos codificados en Base64URL y unidos por puntos: un header que describe el algoritmo, un payload con los claims y una firma calculada sobre los dos primeros. El header y el payload no están cifrados, solo codificados, así que cualquiera que tenga un token puede leerlos. Eso es exactamente lo que hace esta herramienta, y nada más.

Cómo funciona

Pega un token. La herramienta lo divide por los dos puntos, decodifica cada uno de los dos primeros segmentos desde Base64URL (el alfabeto con - y _, sin padding, tal como exige la RFC 7515) a UTF-8 y analiza el resultado como JSON. El header y el payload se muestran formateados, cada uno con su botón de copiar. El tercer segmento se muestra tal cual, porque son los bytes en bruto de la firma y no JSON.

Si el payload incluye los claims de tiempo estándar, se muestran como fechas locales: iat (emitido el), nbf (no válido antes de) y exp (caduca el), todos ellos timestamps Unix en segundos. El indicador de la parte superior compara exp con el reloj de tu dispositivo; un token se considera caducado cuando la hora actual alcanza o supera ese instante. Si no hay un claim exp numérico, no aparece ningún indicador.

Los fallos más habituales: un token con un número de segmentos distinto (un JWE, que va cifrado, tiene cinco), un segmento que no es Base64URL válido o un segmento que, al decodificarlo, no resulta ser JSON. Cada caso muestra un mensaje específico.

La decodificación se hace en tu navegador y el token nunca se transmite. Aun así, un token es una credencial bearer: quien lo tenga puede actuar en nombre de su sujeto hasta que caduque. Es preferible decodificar tokens de un entorno de pruebas, y no pegues nunca un secreto de firma ni una clave privada en ninguna página web.

Qué significa «sin verificar»

La firma demuestra que el token lo emitió quien posee la clave de firma y que no se ha modificado desde entonces. Para comprobarla hace falta la clave: el secreto compartido en los algoritmos HMAC como HS256, o la clave pública del emisor en RS256, ES256 y el resto de algoritmos asimétricos. Esta herramienta no tiene ninguna de las dos, así que no puede decirte si un token es auténtico. Un token que se decodifica sin problemas y no ha caducado puede estar falsificado, revocado o emitido para otra audiencia.

La verificación corresponde al servidor, con la clave obtenida del endpoint JWKS del emisor y el header alg comprobado contra una lista de algoritmos permitidos. Aceptar cualquier algoritmo que indique el header es la vulnerabilidad clásica de JWT: un atacante pone alg a none o sustituye un token RSA por uno HMAC firmado con la clave pública.

Cómo leer los claims

Además de los claims de tiempo, fíjate en iss (quién lo emitió), sub (a quién se refiere), aud (quién debe aceptarlo) y jti (un ID único para la revocación). Los access tokens de los servidores OAuth 2.0 suelen añadir scope o roles; los ID tokens de OpenID Connect añaden campos de perfil como email y name, además de nonce. Los claims personalizados son habituales, pero cada byte del payload viaja con cada petición, así que cuanto más ligero sea el token, mejor.

Equivalente en la línea de comandos

jq puede decodificar el payload directamente, una vez que el segmento se rellena con padding hasta un múltiplo de cuatro caracteres:

TOKEN='eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDAwMDAwMDB9.sig'
printf '%s' "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | awk '{ while (length($0) % 4) $0 = $0 "="; print }' | base64 -d | jq .

Para saber más

Proteger APIs REST con JWT explica cómo emitir, validar y rotar tokens, incluido el ataque de confusión de algoritmos mencionado arriba. Los tokens en sí proceden de los flujos descritos en OAuth 2.0, y los ID tokens en concreto, de OpenID Connect. El conversor de timestamps convierte cualquier valor de claim que el decodificador no muestre ya como fecha, y el generador de hash muestra la primitiva SHA-256 sobre la que se construyen las firmas HS256.