Decodificador JWT

Cómo decodificar un JWT

Un JSON Web Token no es más que tres cadenas base64url unidas por puntos. Decodificarlo consiste en convertir las dos primeras cadenas de nuevo en JSON legible para inspeccionar el encabezado y las reclamaciones sin ningún programa especial. Siga estos pasos.

1. Pegue el token. Copie el token completo — es largo — y péguelo en el campo. Por ejemplo, el token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c se decodifica en un encabezado y una carga útil que son ambos JSON legible.

2. Lea el encabezado. El encabezado indica qué algoritmo firmó el token y su tipo. En el ejemplo anterior es {"alg":"HS256","typ":"JWT"}, lo que significa que el emisor usó un secreto compartido HMAC-SHA256. Si ve «alg»:«none» o un algoritmo que no esperaba, considere el token sospechoso.

3. Inspeccione la carga útil. La carga útil contiene las reclamaciones: campos registrados como sub, iat y exp, más campos de la aplicación como name o role. En el ejemplo, el sujeto es 1234567890, el nombre es Jane Doe y el rol es admin, de modo que este token describe a un usuario concreto y su nivel de permiso.

4. Compruebe las marcas de tiempo. La reclamación iat 1516239022 corresponde al 18 de enero de 2018 a las 01:30:22 UTC, y exp 1516242622 es exactamente una hora más tarde. La herramienta muestra ambas como fechas locales y señala de un vistazo si el token está caducado o sigue siendo válido, lo que es mucho más seguro que comparar grandes enteros a ojo.

5. Confirme la estructura en tres partes. Si el número de segmentos no es tres, si un segmento no es un base64url válido o si el texto decodificado no es JSON, la herramienta muestra un error preciso y localizado en lugar de adivinar. Corrija su copia y vuelva a decodificar.

6. Recuerde lo que no hace la decodificación. Esta página nunca comprueba la firma, el emisor ni la audiencia. Úsela para entender y depurar un token, y luego verifíquelo correctamente dentro de su propio servicio antes de confiar en cualquier reclamación.

¿Qué es un JWT y por qué decodificar no es verificar?

Un JSON Web Token, definido en la RFC 7519, es una forma compacta y segura para URL de representar reclamaciones entre dos partes. Consta de tres partes separadas por puntos. El encabezado es un pequeño objeto JSON que describe el token, normalmente el algoritmo de firma (alg) y el tipo (typ). La carga útil es un objeto JSON de reclamaciones — afirmaciones sobre el usuario o la sesión. La firma es un valor criptográfico derivado de las dos primeras partes. Cada parte se codifica con base64url, una variante de base64 que sustituye + por - y / por _, y omite el relleno = para que el token viaje sin problemas en URL, cabeceras HTTP y cookies. El base64url es una codificación, no un cifrado. Cualquiera que tenga el token puede revertirla en una fracción de segundo, y por eso un JWT nunca debe contener secretos. El encabezado y la carga útil son legibles por el cliente y por cualquiera que intercepte el token; solo la firma depende de una clave. Esa firma es lo que demuestra la integridad: el emisor la calcula sobre encabezado.cargautil con un secreto o una clave privada, y el receptor la recalcula y la compara. Si cambia un solo carácter de la carga útil, la firma deja de coincidir y un servidor bien implementado rechaza el token. La distinción esencial es, por tanto, entre decodificar y verificar. Decodificar, que es lo que hace esta herramienta, es un simple análisis sintáctico que no requiere clave y no demuestra nada. Verificar requiere la clave del emisor, confirma la firma y normalmente también comprueba que el token no ha caducado, que el emisor (iss) y la audiencia (aud) son los esperados y que el algoritmo es uno de los que permite. Un ataque habitual consiste en eliminar la firma y poner alg en «none», o en cambiar RS256 por HS256 para engañar a un servidor y que trate una clave pública como si fuera un secreto HMAC. Un decodificador mostrará sin problema ese token manipulado; solo un verificador lo rechaza. Use la decodificación para inspeccionar y depurar, y la verificación para conceder acceso.

Aplicaciones comunes

1. Depurar un flujo de autenticación. Inicia sesión y recibe «401 Unauthorized» en cada petición. Al decodificar el token de acceso ve {"exp":1516242622} y observa que la caducidad es de 2018: el reloj del servidor o la vida útil del token están mal. No se necesita ninguna clave.

2. Leer la identidad que representa un token. Un ingeniero de soporte pega el token de un cliente y ve {"sub":"1234567890","role":"admin","scope":"orders:read"} para entender qué permisos cree tener el cliente, sin tocar la base de datos de producción.

3. Comprobar la vida útil durante un incidente. Si los tokens deben durar una hora pero una muestra muestra iat y exp separados por sesenta segundos, la lógica de refresco o la configuración están mal, y el decodificador lo revela al instante.

4. Inspeccionar tokens de identidad de terceros. OpenID Connect devuelve un id_token con campos como iss, aud y email. Decodificarlo muestra qué proveedor lo emitió y a qué cliente está destinado, algo útil al integrar un nuevo SSO.

5. Enseñanza y revisión de código. Al revisar un cambio de autenticación, pegar un JWT de ejemplo en el decodificador muestra de inmediato a todo el equipo la diferencia entre un token que solo lleva un identificador de usuario y uno que lleva toda una lista de permisos.

6. Auditar reclamaciones por privacidad. La decodificación revela si datos sensibles como un correo electrónico o un rol interno se han filtrado en la carga útil, porque todo lo que contiene es visible para el cliente y para cualquiera que capture el token.

Riesgos de seguridad frecuentes

El primer riesgo es confiar en la carga útil. Como base64url es reversible, una reclamación decodificada como «role»:«admin» es solo una afirmación, no un hecho, hasta que se verifica la firma. El segundo es la confusión de «alg»:«none»: un atacante puede reconstruir el encabezado sin firma, y un servidor que no fija el algoritmo esperado puede aceptarlo. El tercero es la degradación de RS256 a HS256, en la que se engaña a un servidor para que verifique un token asimétrico usando la clave pública como secreto HMAC. El cuarto es tratar un token como una sesión: como un JWT es autónomo, sigue siendo válido hasta exp incluso después de cerrar sesión, a menos que añada una lista de revocación por jti o vidas útiles cortas. Por último, nunca guarde un JWT en localStorage si es posible un fallo XSS; una cookie httpOnly y Secure es más segura. Este decodificador no realiza deliberadamente ninguna de estas comprobaciones, y por eso debe verificar en otro lugar.

JWT u tokens opacos

Un token opaco es una cadena aleatoria cuyo significado vive en una base de datos; el servidor la consulta, de modo que puede revocarse al instante y no revela nada por sí mismo. Un JWT es autónomo: el servidor puede confiar en él comprobando una firma sin consultar la base, lo que escala bien entre microservicios pero dificulta la revocación. Ese equilibrio lo resume todo. Use JWT cuando muchos servicios deban validar un token de forma independiente, cuando necesite credenciales de corta duración o cuando un tercero deba verificar su token. Use tokens opacos cuando importen más la revocación instantánea, un tamaño mínimo o mantener todo el estado en el servidor. Muchos sistemas combinan ambos: un token de acceso JWT de corta duración para la velocidad y un token de refresco opaco almacenado y revocable en la base de datos. Decodificar un JWT deja clara su naturaleza autónoma, ya que cada reclamación está en la propia cadena.

Reclamaciones registradas y privadas

La RFC 7519 reserva siete nombres de reclamación para que los distintos sistemas coincidan en su significado: iss, sub, aud, exp, nbf, iat y jti. Todo lo demás es una reclamación privada elegida por el emisor, como role, scope, tenant o email. Las reclamaciones registradas debe tratarlas cualquier receptor; las privadas solo tienen sentido para las aplicaciones que las definen. De ahí se derivan dos consecuencias prácticas. Primero, compruebe siempre exp y aud, aunque su framework ya lo haga, porque un token emitido para una API no debe ser aceptado por otra. Segundo, mantenga las reclamaciones privadas pequeñas y no sensibles: un identificador numérico de usuario es correcto, pero un perfil completo o un código de restablecimiento de contraseña no tienen cabida en un token que cualquier cliente puede leer.

Utilidades Relacionadas

• Formateador JSON — Validador en Línea
• Codificador y Decodificador Base64 en Línea
• Generador de Contraseñas Seguras en Línea
• Codificador y Decodificador de URL
• Generador de UUID — Crear UUID v4 en Línea
• Eliminar Líneas Duplicadas — Herramienta Gratis