Decodificador de JWT

Qué es realmente un JWT

Un JSON Web Token (RFC 7519) es tres segmentos codificados en Base64URL unidos por puntos:

<header>.<payload>.<signature>

Los primeros dos segmentos son objetos JSON. El tercero es una firma binaria que prueba que los primeros dos vinieron de alguien que tiene la clave de firma del emisor. Cualquiera puede poner un JWT en un decodificador — incluyendo este — y leer el encabezado y la carga útil. Solo alguien con la clave de verificación puede confirmar la firma.

Trata los JWT decodificados como entrada de usuario no confiable a menos que también hayas verificado la firma. Esta herramienta solo decodifica — por diseño no pedimos claves, porque pegar tu secreto HMAC de producción en un sitio web aleatorio es una pesadilla de seguridad.

Qué va en el encabezado

Típicamente dos campos:

• alg — el algoritmo de firma (HS256, RS256, ES256, etc.).
• typ — normalmente "JWT".

A veces verás kid (clave ID) cuando el emisor rota claves, o x5t cuando certificados X.509 están involucrados. Cualquier otra cosa es específica de la implementación.

Qué va en la carga útil (las reclamaciones)

La carga útil es solo un objeto. RFC 7519 reserva algunos nombres de campo con significados estándar:

Más allá de estos, los emisores agregan reclamaciones personalizadas libremente: IDs de usuario, roles, nivel de plan, lo que sea. Esta herramienta destaca los estándar y muestra estado de expiración prominentemente.

El desastre alg=none

Históricamente, las bibliotecas JWT aceptaban tokens con "alg": "none" y los trataban como autenticados. Combinado con el hecho de que cualquiera puede fabricar un encabezado, esto significaba que los atacantes podían forjar tokens que omitían completamente la verificación.

Las bibliotecas modernas rechazan none por defecto, pero la lección permanece: siempre verifica con el algoritmo esperado explícitamente, nunca confíes en el algoritmo declarado dentro del encabezado. Si tu biblioteca tiene una opción algorithms: ['RS256'], establécela.

HS256 vs RS256

HS256 es simétrico — el mismo secreto firma y verifica. Rápido, simple, pero el verificador debe tener el secreto, lo que significa que también puede forjar tokens. Úsalo para servicios de primera parte que se confían completamente entre sí.

RS256 (y ES256) es asimétrico — una clave privada firma, una clave pública verifica. Los verificadores solo obtienen la clave pública, así que no pueden forjar. Úsalo para tokens cruzando límites de confianza (API de terceros, servicios distribuidos).

Casos de uso comunes

• Tokens de autenticación emitidos después del inicio de sesión (a menudo vía OAuth2 / OIDC).
• Tokens de acceso API para llamadas de servicio a servicio sin estado.
• Enlaces mágicos para inicio de sesión por correo sin contraseña.
• Verificación de correo y flujos de restablecimiento de contraseña.
• Firmas de webhook (menos común; HMAC desnudo es más típico).

Privacidad en esta página

La herramienta decodifica en tu navegador vía Base64URL + JSON.parse. No guardamos tu token, no registramos solicitudes, y no tenemos un endpoint del servidor para enviarlo. Abre DevTools Network y mira — tráfico cero.

Si tu token contiene secretos reales de producción, prefiere decodificar localmente con un CLI como jq. Los decodificadores públicos (incluyendo este) son convenientes pero no apropiados para credenciales en vivo.

Herramientas relacionadas

• Codificador Base64 — ve cómo se ve cada segmento antes/después.
• Generador de Hash — calcula HMAC manualmente para verificación de HS256.

¿Es seguro pegar un JWT en un decodificador?

Decodificar el encabezado y la carga útil es seguro en el sentido de que ya fueron diseñados para ser legibles. Pero si el token otorga acceso a algo real, trata el acto de pegarlo en una herramienta de terceros como una fuga de credenciales — asume que el operador de la herramienta (o cualquiera con acceso de red entre tú y ellos) ahora lo tiene. Decodifica tokens de producción localmente con jq o tu IDE en su lugar.

¿Por qué esta herramienta no verifica la firma?

Para verificar, necesitaríamos tu clave de firma (HS256) o clave pública (RS256). Pedir claves en una herramienta del navegador sería una bandera roja gigante. La verificación pertenece en el código de tu aplicación usando una biblioteca revisada, no en una página web pública.

¿Por qué mi token tiene caracteres =?

No los tiene — JWT usa Base64URL, que elimina el relleno. Si ves =, el token probablemente fue re-codificado en algún lugar como Base64 estándar. La mayoría de decodificadores (incluyendo este) lo toleran, pero el JWT que cumple con la especificación no debería tenerlo.

¿Cuál es la vulnerabilidad alg=none?

Las bibliotecas más antiguas aceptaban tokens donde el encabezado declaraba "alg": "none" y omitía verificación de firma completamente. Los atacantes explotaban esto forjando cargas útiles arbitrarias. La solución es validar con una lista explícita de algoritmos permitidos en tu verificador — nunca confíes en el campo alg en el encabezado.

¿HS256 o RS256?

Simétrico (HS256) cuando ambos lados se confían completamente entre sí y pueden compartir un secreto. Asimétrico (RS256/ES256) cuando no quieres que los verificadores puedan forjar tokens, o cuando las claves cruzan un límite de confianza.

¿Cómo revoco un JWT?

No puedes, no directamente — los JWT son sin estado. Soluciones alternativas: mantén tokens de corta duración y usa tokens de actualización; mantén una lista de bloqueo del lado del servidor con clave por jti; o usa tokens opacos con sesiones del lado del servidor en lugar de JWT.

¿Cuál es la diferencia entre exp y nbf?

exp es la hora más reciente en que el token es válido (después de esto expira). nbf es la hora más temprana en que es válido (antes de esto no debería ser aceptado). Ambos son marcas de tiempo de Unix en segundos. iat es cuándo fue emitido el token — informacional.