Decodificador JWT
Decodifica e inspecciona JSON Web Tokens localmente: cabecera, carga útil y claims de expiración.
Cargando Decodificador JWT… Si no ocurre nada, activa JavaScript.
Un JSON Web Token (JWT) es una cadena compacta y segura para URL que codifica un conjunto firmado de claims (afirmaciones sobre un usuario, una sesión o un permiso) en un formato que cualquier parte que tenga la clave correcta puede verificar de forma independiente. Definido por el RFC 7519 (2015) y parte de la familia de estándares JOSE (firma y cifrado de objetos JSON), los JWT se convirtieron rápidamente en el mecanismo dominante para la autenticación sin estado y la autorización de API en arquitecturas web, móviles y de microservicios. Un JWT consta de tres segmentos codificados en Base64url y separados por puntos: la cabecera (metadatos del algoritmo), la carga útil (los claims) y la firma.
Ejemplos
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.<sig>
Header {"alg":"HS256","typ":"JWT"} · Payload {"sub":"1234567890","name":"John Doe"}
Un JWT son tres partes en Base64url unidas por puntos: cabecera.carga_útil.firma.
Preguntas frecuentes
¿Se sube mi token a un servidor?
¿Cuáles son las tres partes de un JWT?
¿Cuándo debería usar un JWT en mi propia aplicación?
¿En qué se diferencia un JWT de una cookie de sesión?
¿Esta herramienta verifica la firma del JWT?
¿Qué significan los claims estándar de marca de tiempo?
¿Puede usarse un JWT sin firma (alg: none)?
¿Son las cargas útiles de los JWT privadas y confidenciales?
¿Cuál es la diferencia entre HS256 y RS256?
¿Cuál es un error común que cometen los desarrolladores con los JWT?
Acerca de Decodificador JWT
Los JWT aparecen en prácticamente todos los flujos de autenticación modernos. Los tokens de acceso de OAuth 2.0 se emiten casi universalmente como JWT. Los tokens de identidad de OpenID Connect son JWT que llevan los claims de identidad del usuario autenticado. Los sistemas de inicio de sesión único pasan JWT entre proveedores de identidad y proveedores de servicios. Las funciones serverless y los workers de borde validan JWT localmente sin consultar una base de datos, habilitando una autenticación sin estado y escalable horizontalmente. Las apps móviles guardan los JWT como tokens de portador (bearer) y los incluyen en la cabecera Authorization de cada petición de API. Entender qué hay dentro de un token (qué permisos otorga, cuándo expira y quién lo emitió) es una tarea diaria para cualquier ingeniero de backend o de seguridad.
Esta herramienta decodifica la cabecera y la carga útil de cualquier JWT enteramente dentro de tu navegador. Decodifica en Base64url cada segmento, analiza el JSON y presenta los claims en un formato legible. Las marcas de tiempo numéricas (iat, exp, nbf) se convierten automáticamente en fechas legibles para que veas al instante si un token ha expirado. La firma se muestra tal cual, pero deliberadamente no se verifica: la verificación requiere el secreto del emisor (para HMAC) o su clave pública (para RSA/ECDSA), y nunca deberías pegar ninguno de los dos en una herramienta online no confiable. Como la decodificación ocurre localmente, ni siquiera el propio token sale de tu dispositivo.
Algunos puntos de seguridad a tener en cuenta: los JWT están firmados pero no cifrados por defecto; la carga útil solo está codificada en Base64url, lo que significa que cualquiera que intercepte el token puede leer sus claims. Nunca incluyas datos personales sensibles (contraseñas, números de tarjeta) en la carga útil de un JWT. El ataque alg: none es una vulnerabilidad conocida en bibliotecas JWT ingenuas que aceptan tokens sin firmar; usa siempre una biblioteca bien auditada que valide explícitamente el algoritmo. Comprueba además el claim exp antes de confiar en un token: una firma válida no significa que el token siga activo.
El auge del JSON Web Token
Los JSON Web Token fueron introducidos por el Internet Engineering Task Force (IETF) como parte del grupo de trabajo JOSE (firma y cifrado de objetos JSON), con el RFC 7519 publicado en mayo de 2015. El objetivo era crear un formato de credencial compacto y autónomo que pudiera reemplazar las verbosas y complejas aserciones SAML en XML usadas en los sistemas empresariales de inicio de sesión único. El diseño delimitado por puntos y codificado en Base64url se eligió deliberadamente para ser seguro en URL y caber cómodamente dentro de una cabecera HTTP.
La adopción fue explosiva. A los pocos años de su publicación, casi todos los marcos de autenticación importantes, desde Auth0 hasta Firebase Authentication y AWS Cognito, se habían estandarizado en los JWT como su formato de token. El sitio jwt.io, lanzado por Auth0 como herramienta de depuración, se convirtió en una de las utilidades para desarrolladores más visitadas de internet. Esta popularidad también atrajo el escrutinio: los investigadores de seguridad catalogaron una serie de vulnerabilidades de implementación (el fallo 'alg: none', los ataques de confusión de algoritmos) que afectaban a implementaciones de bibliotecas ingenuas, lo que impulsó una oleada de mejoras en las bibliotecas JWT de todos los lenguajes de programación.
Una decisión de diseño interesante de los JWT es que la carga útil es legible por cualquiera: la firma garantiza la integridad, pero no el secreto. Esto fue intencionado: los diseñadores querían que los tokens fueran depurables sin una clave, lo que permite que herramientas como los decodificadores de JWT ayuden a los desarrolladores a inspeccionar tokens durante el desarrollo. La contrapartida es que los desarrolladores deben ser disciplinados sobre qué claims incluyen, una lección que han aprendido por las malas los equipos que enviaron por accidente JWT con datos sensibles de usuarios.