Seguridad

Inspector de JWT

Pega un JSON Web Token y lee su header, payload, claims, caducidad y estado de la firma de un vistazo. Cuando necesites confirmar una firma o generar un token nuevo, la herramienta acepta secretos HMAC y claves RSA, ECDSA o EdDSA, y lo ejecuta todo en el navegador sin enviar el token ni la clave a un servidor.

  • El análisis, la verificación y la firma ocurren de forma local en el navegador, sin subidas
  • El header, el payload y la firma se separan automáticamente y se muestran como JSON legible
  • Los algoritmos habituales HMAC, RSA, PS, ECDSA y EdDSA verifican en cuanto proporcionas el material de clave adecuado
  • Las claims de caducidad, emisión y «no antes» se muestran como fechas reales para detectar rápido los problemas de desfase de reloj
tools/Inspector de JWT
Opcional

Los algoritmos HMAC necesitan un secreto compartido. RSA, PS, ES y EdDSA necesitan material PEM o JWK.

Esperando entrada
Pega un token a la izquierda y su header y payload aparecerán aquí al instante.

Resumen

Lee tokens, verifica firmas y produce tokens de prueba nuevos en un solo lugar, con cada operación ejecutándose en el navegador.

  1. 01

    Decodificación completa del token

    Separa el token en header, payload y firma, y los muestra como JSON legible sin ningún trabajo manual de Base64URL.

  2. 02

    Verificación con varios algoritmos

    Admite de HS256 a HS512, de RS256 a RS512, de PS256 a PS512, de ES256 a ES512 y EdDSA en cuanto proporcionas la clave adecuada.

  3. 03

    Marcas de tiempo legibles

    Los valores de caducidad, emisión y «no antes» aparecen como fechas reales, así que el desfase de reloj y los problemas de caducidad destacan de inmediato.

  4. 04

    Generar tokens firmados

    Edita el header y el payload, elige un algoritmo, pega una clave que coincida y se produce un token nuevo a medida que escribes.

  5. 05

    Detección inteligente de claves

    Reconoce secretos compartidos, claves PEM públicas y privadas, certificados X.509 y objetos JWK, y luego los importa con el método adecuado para el algoritmo seleccionado.

  6. 06

    Solo procesamiento local

    Los tokens y las claves se quedan en el navegador. No se envía nada a un servidor ni a una API de terceros mientras la herramienta está abierta.

Cómo usarla

El modo Inspeccionar es para tokens existentes y el modo Firmar es para tokens nuevos que necesitas para pruebas o depuración. Ambos comparten el mismo panel.

  1. 01

    Pega un token existente en el modo Inspeccionar. El header y el payload se decodifican al instante.

  2. 02

    Para confirmar la firma, pega el secreto compartido, la clave pública PEM o el JWK correspondiente en el campo de clave de verificación.

  3. 03

    Cambia al modo Firmar cuando necesites construir un token nuevo a partir de un header y un payload JSON editables.

  4. 04

    Elige un algoritmo y proporciona el secreto o la clave privada que coincidan. El token se regenera a medida que escribes.

  5. 05

    Copia el token resultante del panel de salida y úsalo en tu llamada a la API, tu fixture de prueba o tu integración local.

Detalles

Cada tarea se centra en una parte distinta del token. Elegir el modo y el campo adecuados mantiene la depuración directa.

  • Usa el modo Inspeccionar sin una clave para ver qué claims lleva un token y si ha caducado.
  • Proporciona el secreto o la clave pública correspondiente en el modo Inspeccionar para confirmar que el token realmente proviene del emisor esperado.
  • Usa el modo Firmar para producir un token para una API local, una prueba unitaria o un servicio mock sin pasar por todo el flujo de inicio de sesión.
  • Los algoritmos HMAC firman y verifican con el mismo secreto compartido, lo que resulta cómodo al depurar.
  • RSA, PS, ECDSA y EdDSA firman con una clave privada y verifican con una clave pública, así que prepara la que corresponda a cada función.
  • Pasa el cursor sobre exp, iat y nbf en el payload para ver la fecha exacta, lo que suele revelar rápido los problemas de desfase de reloj.

Casos de uso

Dondequiera que una aplicación use autenticación, autorización o enrutamiento basado en claims, este inspector elimina el ir y venir entre herramientas.

  1. Depurar inicio de sesión y autenticación

    Revisa el subject, los roles, los scopes, la caducidad y el estado de la firma de un token de inicio de sesión mientras rastreas respuestas 401 o 403.

  2. Integración de API de backend

    Genera tokens firmados predecibles para APIs locales, servicios mock y pruebas automatizadas en lugar de completar todo el flujo de inicio de sesión cada vez.

  3. Revisión de tokens de terceros

    Decodifica un token emitido por un socio y confirma que el algoritmo, el emisor, la audience y la caducidad coinciden con lo que espera tu backend.

  4. Solución de problemas de SSO y OIDC

    Compara aud, iss y auth_time entre entornos para encontrar diferencias de configuración sin inspeccionar las respuestas en crudo.

  5. Revisión de seguridad y regresión

    Confirma que los tokens de producción usan el algoritmo esperado y que ningún secreto ni dato personal sensible se coló en el payload por error.

  6. Comprobaciones de webhooks y callbacks

    Cuando un webhook se entrega como un JWT, verifica su firma, su origen y su frescura antes de confiar en el contenido.

Ver también

Cuando un header o payload decodificado es difícil de leer, abre Formateador de JSON para ordenar el JSON y luego cópialo de vuelta al modo Firmar. Para inspeccionar un solo segmento Base64URL fuera del token, Codificador y decodificador Base64 es la forma más rápida de experimentar con la codificación y la decodificación. Para usos que no son JWT, como firmar peticiones de API, firmas de webhook o resúmenes HMAC independientes, abre Generador de HMAC . Cuando necesites un secreto desechable para un token de prueba HS256 local, genera uno con Generador de contraseñas en lugar de reutilizar credenciales reales.Para comparar los payloads decodificados de dos JWT emitidos —por ejemplo, para revisar cambios en las claims, scopes más restringidos o ajustes de audience—, pega los dos documentos JSON en Diferencias de JSON para un diff estructural indexado por ruta, con resaltado a nivel de palabra para las claims de cadena larga. Para rastrear qué petición transportaba de verdad un token en su cabecera Authorization, entrega el mensaje completo a Analizador de mensajes HTTP , que dispone juntos la cabecera Authorization, las cookies y el cuerpo; luego vuelve aquí a verificar el token. Cuando un token se firma con RS256 o ES256, la clave pública de verificación suele estar en un certificado X.509; decodifícalo con Decodificador de certificados para leer el sujeto, la validez y los detalles de la clave antes de confiar en el emisor.

Qué hay dentro de un JWT

Un token son tres segmentos separados por puntos. Saber qué contiene cada uno facilita detectar qué parte hay que mirar cuando algo va mal.

  1. Header

    Describe el tipo de token y el algoritmo de firma. Suele contener typ y alg, y a veces kid para identificar qué clave se usó.

  2. Payload

    Lleva claims como el emisor, el subject, la audience, la caducidad y tus propios datos de aplicación. Está codificado en Base64URL, no cifrado, así que cualquiera puede decodificarlo y leerlo.

  3. Firma

    Se calcula a partir del header, el payload y una clave. Permite detectar manipulaciones y confirmar el emisor, y no se puede reproducir sin la clave correcta.

Claims estándar del payload

El RFC 7519 define un conjunto de nombres de claim registrados en los que se apoya casi cualquier emisor. Usa la referencia siguiente para reconocer los campos habituales y sus valores típicos mientras depuras tokens.

iss
Emisor
Identifica el servicio o la autoridad que produjo el token. Los receptores suelen compararlo con una lista de emisores de confianza.
e.g. https://auth.example.com
sub
Subject
Identifica al principal que representa el token, normalmente un ID de usuario. Debería ser único dentro del emisor.
e.g. user_1234567890
aud
Audience
Declara qué servicio o cliente puede consumir el token. Los receptores deberían confirmar que su propio identificador aparece en aud.
e.g. https://api.example.com
exp
Caducidad
Segundos Unix a partir de los cuales el token no debe aceptarse. La mayoría de las bibliotecas rechazan automáticamente los tokens caducados.
e.g. 1710003600
nbf
No antes
Segundos Unix antes de los cuales el token todavía no es válido. Útil para tokens que deben activarse en un momento concreto.
e.g. 1709996400
iat
Emitido en
Segundos Unix que registran cuándo se creó el token. Ayuda a razonar sobre la antigüedad del token y el desfase de reloj.
e.g. 1709996400
jti
ID del token
Un identificador único del token. Útil para la protección contra reenvíos y para correlacionar tokens con los registros de auditoría del servidor.
e.g. a1b2c3d4-...-e5f6
auth_time
Hora de autenticación
Registra cuándo se autenticó realmente el usuario. Habitual en OpenID Connect y en los flujos de SSO que exigen un inicio de sesión reciente.
e.g. 1709992800

Buenas prácticas

Trata un JWT como texto plano firmado, no como un contenedor privado, y desaparecen la mayoría de los errores habituales.

  • No confíes en las claims de un token hasta que hayas verificado la firma con el secreto o la clave pública correctos.
  • JWT está firmado, no cifrado. No guardes nunca contraseñas, claves ni datos personales sensibles en el payload.
  • Guarda las claves de firma de producción y las claves privadas en un sistema de gestión de claves. No las pegues en herramientas del navegador, chats ni capturas de pantalla.
  • Haz coincidir el algoritmo con el tipo de clave. Un token firmado con HS256 no se puede verificar con HS512, y las claves públicas RSA no pueden verificar tokens HMAC.
  • Al depurar problemas de autenticación, revisa pronto exp, iat y nbf y compara los relojes del emisor y del receptor. El desfase de reloj se pasa por alto con facilidad.
  • Para los tokens de larga duración, combínalos con lógica de refresco y una estrategia de revocación para que un token filtrado siga siendo útil el menor tiempo posible.

Limitaciones

Saber lo que la herramienta no cubre mantiene realistas las expectativas sobre la seguridad y la compatibilidad de los JWT.

  • Solo se admiten los tokens JWS compactos. Los tokens JWE cifrados quedan fuera del alcance.
  • Los tokens y las claves nunca se conservan. Todo se libera cuando cierras la pestaña.
  • Un JSON no válido en el header o el payload impedirá firmar un token hasta que se corrija el JSON.
  • La herramienta no es un servicio de gestión de claves. Evita pegar claves de larga duración o maestras en cualquier herramienta en línea, incluida esta.
  • Los payloads extremadamente grandes pueden ralentizar el editor, aunque el procesamiento sigue siendo local en lugar de truncarse o subirse.

Preguntas frecuentes

Preguntas frecuentes sobre los tokens firmados frente a los cifrados, los fallos de verificación, los algoritmos admitidos y cómo los datos se mantienen en local.

¿Un JWT está cifrado?

La mayoría de los JWT están firmados, no cifrados, lo que significa que cualquiera puede decodificar el payload en cuanto tiene el token. Si necesitas cifrado, el estándar que buscas es JWE en lugar de JWS.

¿Por qué sigue fallando la verificación de la firma?

Las causas habituales son una clave que no coincide, un algoritmo distinto del que hay en el header, un payload que se modificó después de firmar o un token emitido con otra familia de claves. Compara el alg del header con la clave que proporcionaste.

¿Puedo usar esto con secretos de producción?

Usa la herramienta para inspección, depuración y generación de tokens de prueba local. Guarda los secretos de producción y las claves privadas dentro de un sistema seguro de gestión de claves, no en herramientas del navegador ni en pantallas compartidas.

¿La página envía mi token o mi clave a algún sitio?

No. El análisis, la verificación y la firma ocurren todos en tu navegador. La página no incluye ninguna llamada de red que envíe tu token o tu clave a un servidor.

¿Qué algoritmos se admiten?

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 y EdDSA, lo que cubre los valores por defecto de la mayoría de los frameworks de backend modernos.

¿Por qué exp e iat aparecen como fechas?

El estándar guarda esas claims como segundos de la época Unix. La herramienta las convierte en fechas legibles para que puedas comprobar rápido los problemas de caducidad y de desfase de reloj.

¿Puedo confiar en el payload decodificado?

Solo después de una verificación de firma correcta. Decodificar por sí solo demuestra que el payload es JSON válido, no que provenga del emisor esperado ni que se mantuviera intacto en tránsito.

Herramientas relacionadas

Sigue con las tareas de seguridad e identidad con herramientas afines para generar contraseñas, calcular hashes y comprobar firmas.