Decodificador de JWT

Pega un JWT (JSON Web Token) para decodificar al instante su encabezado y su carga útil, incluida la comprobación de la fecha de expiración (exp). No se realiza verificación de firma ni se requiere clave secreta.

Reclamaciones registradas (Registered Claims) más comunes

Reclamación Nombre Descripción
iss Issuer (emisor) Cadena o URL que identifica a la entidad que emitió el token.
sub Subject (sujeto) La entidad a la que hace referencia el token (normalmente un ID de usuario).
aud Audience (destinatario) Identificador del destinatario o la API para la que está pensado el token.
exp Expiration Time (expiración) Momento (en segundos Unix) a partir del cual el token ya no debe aceptarse.
nbf Not Before (no antes de) Momento (en segundos Unix) antes del cual el token no debe aceptarse.
iat Issued At (fecha de emisión) Momento (en segundos Unix) en el que se emitió el token.
jti JWT ID Identificador único del token, utilizado a menudo para detectar ataques de repetición (replay).

Consejos

  • El JWT que pegas se procesa por completo en JavaScript dentro de tu navegador y nunca se envía a los servidores de toolbase.cc, así que cualquier dato personal o de autenticación que contenga el token permanece privado.
  • Un JWT es una cadena Base64URL compuesta por tres partes —encabezado, carga útil y firma— separadas por puntos. El encabezado y la carga útil son texto plano que cualquiera puede decodificar (Base64 es una codificación, no un cifrado), así que nunca incluyas información sensible como contraseñas en la carga útil.
  • Si una petición a una API falla con un error 401 porque el token ha expirado, revisar el valor de la reclamación exp con esta herramienta suele ser la forma más rápida de confirmar la causa.
  • El algoritmo de firma puede consultarse en el encabezado alg. Las implementaciones que aceptan alg: none son vulnerables al conocido ataque «alg=none» de JWT, por lo que el servidor siempre debe restringir explícitamente los algoritmos permitidos.

Preguntas frecuentes

Sí. El encabezado y la carga útil de un JWT están codificados en Base64URL, no cifrados, por lo que cualquiera puede leer su contenido. Nunca se debe incluir información sensible, como contraseñas o números de tarjeta de crédito, en la carga útil.

No, esta herramienta solo decodifica y muestra el encabezado y la carga útil; no verifica la firma. Verificar una firma requiere una clave secreta (o una clave pública RSA/EC) que solo conoce el emisor del token, e introducir esa clave en una herramienta del navegador sería en sí mismo un riesgo de seguridad.

La mayoría de las API y servidores de autenticación rechazan un JWT cuya reclamación exp sea anterior a la hora actual, devolviendo normalmente un error 401 Unauthorized. En ese caso hay que obtener un nuevo token, por ejemplo mediante un token de actualización (refresh token).
ツールくん

A propósito — Cómo el JWT hace posible la «autenticación sin estado»

El JWT (JSON Web Token) fue estandarizado por el IETF como RFC 7519 en 2015. La autenticación tradicional basada en sesiones exigía que el servidor mantuviera una tabla de correspondencia entre los ID de sesión y los datos del usuario, pero el JWT incrusta directamente la información del usuario dentro del propio token y utiliza una firma para detectar manipulaciones. Esto permite que el servidor verifique el estado de autenticación sin mantener un almacén de sesiones, un enfoque conocido como «autenticación sin estado», por lo que los JWT se usan ampliamente en sistemas distribuidos y microservicios repartidos entre varios servidores.

La estructura de un JWT consta de tres partes —«encabezado.carga útil.firma»— cada una codificada en Base64URL y unidas por puntos. Lo esencial es que el encabezado y la carga útil están simplemente codificados, no cifrados. Cualquiera puede decodificarlos y leer su contenido, así que un JWT garantiza que los datos no han sido manipulados, no que su contenido permanezca en secreto. Si necesitas mantener información confidencial, debes recurrir a otra especificación que añade cifrado real, llamada JWE (JSON Web Encryption).

Los esquemas de firma se dividen a grandes rasgos en dos categorías: los basados en HMAC (como HS256), en los que el emisor y el receptor comparten la misma clave secreta, y los de clave pública (como RS256 y ES256), en los que una clave privada firma el token y una clave pública lo verifica. Desde que el JWT fue adoptado como formato de los tokens de acceso e ID de OAuth 2.0 y OpenID Connect, se ha convertido en el formato estándar de facto para la infraestructura de autenticación web.