Codificador/Decodificador JWT

Decodifica JWT y verifica firmas HMAC (HS256/384/512) en el navegador. Inspecciona header, payload y claims, y valida exp, nbf e iat al instante.

Modo

Decodificar

Decodificar un token JWT existente

Codificar

Crear un nuevo token JWT

Token JWT para Decodificar

Open file

Clear

Copy

Paste

Verificar firma con secreto (HS256/384/512)

Token JWT

Clear

Copy

Download text

¿Tienes comentarios? Reporta errores, sugiere funciones o comparte tus ideas — leemos todos

Codificador/Decodificador JWT - Crear y Decodificar JSON Web Tokens Online

Una potente herramienta online de codificación y decodificación JWT que le permite crear nuevos tokens JWT o decodificar, inspeccionar y comprender tokens existentes al instante. Perfecto para desarrolladores, profesionales de seguridad y cualquiera que trabaje con autenticación basada en JWT, OAuth 2.0 y seguridad de API.

¿Qué es un JWT y cómo está estructurado?

Un JSON Web Token (JWT, pronunciado "yot") es un estándar abierto (RFC 7519) para representar declaraciones como una cadena compacta y URL-safe. Un JWT tiene tres partes codificadas en Base64URL unidas por puntos: header.payload.signature. La cabecera declara el algoritmo de firma y el tipo ({"alg":"HS256","typ":"JWT"}). El payload contiene claims como sub (sujeto), iss (emisor), exp (expiración) y datos personalizados. La firma se calcula hasheando el header+payload con un secreto (HMAC) o firmando con una clave privada (RSA/ECDSA). El token es base64url, no base64, así que es seguro en URLs y cabeceras HTTP. Los JWT son sin estado: el servidor valida la firma en cada petición sin consultar la base de datos. RFC 7519 es la especificación JWT; RFC 7515 cubre JWS (firmado) y RFC 7516 cubre JWE (encriptado).

¿Qué es la vulnerabilidad alg=none y cómo prevenirla?

alg=none es la vulnerabilidad JWT más famosa, listada en el OWASP API Security Top 10. Un token firmado con alg=none no tiene firma alguna — pero muchas bibliotecas antiguas lo aceptaban como "válido" porque honraban el campo algoritmo de la cabecera sin verificar contra una lista blanca. Un atacante podía tomar un token real, cambiar la cabecera a {"alg":"none"}, eliminar la firma, modificar el payload (p. ej., role=admin) y el validador roto lo dejaba pasar. La solución es mantener una lista blanca estricta de algoritmos aceptables en el servidor (p. ej., solo HS256 o RS256) y rechazar todo lo demás — nunca confíe en el claim alg del propio token. El bug compañero es la confusión HS256/RS256: un atacante envía un token HS256 firmado con la clave pública RSA del servidor como secreto HMAC. Siempre fije el algoritmo esperado por clave.

¿Cuál es la diferencia entre HS256, RS256 y ES256?

HS256 (HMAC-SHA256) usa un único secreto compartido para firmar y verificar — rápido y simple, pero cualquier parte que pueda verificar también puede falsificar. Úselo solo cuando emisor y verificador son el mismo servicio. RS256 (RSA-SHA256) usa criptografía asimétrica: una clave privada firma, una pública verifica. Es el estándar para OAuth/OIDC porque los proveedores de identidad (Auth0, Okta, Google) publican un endpoint JWKS (JSON Web Key Set) con claves públicas que los clientes obtienen para verificar tokens. ES256 (ECDSA P-256) también es asimétrico pero usa curvas elípticas, produciendo firmas mucho más cortas (~64 bytes vs ~256 bytes en RS256) — mejor para escenarios con ancho de banda limitado. EdDSA (RFC 8037) con Ed25519 es la recomendación moderna: más rápido, más pequeño y resistente a muchos ataques de temporización. Evite RS256 con claves de menos de 2048 bits.

¿Cuáles son los claims registrados estándar (iss, sub, aud, exp, nbf, iat, jti)?

RFC 7519 define siete claims registrados, todos opcionales pero recomendados. iss (emisor) identifica quién creó el token. sub (sujeto) es el ID de usuario. aud (audiencia) lista los destinatarios previstos — su servicio debe rechazar tokens donde su identificador no esté en aud. exp (expiración) es un timestamp Unix tras el cual el token debe rechazarse — manténgalo corto (15 min para tokens de acceso). nbf (not before) es el momento más temprano en que el token es válido, útil para activación programada. iat (issued at) registra cuándo se creó el token. jti (JWT ID) es un identificador único por token, permite listas de revocación o detección de repetición. Todos los claims de tiempo son NumericDate (segundos Unix desde 1970 UTC). Valide siempre exp, nbf, iss y aud — omitir cualquiera es un bypass común.

¿Dónde debo almacenar JWT en el navegador — cookie o localStorage?

Ninguno es perfecto. localStorage es vulnerable a XSS: cualquier script en su origen puede leerlo y exfiltrar el token. Las cookies son vulnerables a CSRF si no se configuran bien, pero las mitigaciones son bien conocidas. El patrón recomendado por OWASP es cookies httpOnly + Secure + SameSite=Strict (o Lax) para el JWT, combinadas con un token CSRF en cabecera para peticiones que cambian estado. httpOnly bloquea el acceso JavaScript (derrota exfiltración por XSS), Secure fuerza HTTPS, y SameSite limita envío entre sitios. Para SPA + API en orígenes distintos, puede necesitar SameSite=None; Secure más CORS explícito. Evite por completo guardar refresh tokens de larga vida en localStorage. Si debe usar localStorage, trate cualquier XSS como una toma completa de cuenta e invierta fuertemente en cabeceras Content Security Policy.

Codificador/Decodificador JWT — Decodifica JWT y verifica firmas HMAC (HS256/384/512) en el navegador. Inspecciona header, payload y claims, y valida ex — **Codificador/Decodificador JWT**

¿Cómo funcionan los refresh tokens y por qué los necesito?

Los tokens de acceso JWT deben ser de vida corta (5-15 minutos) para que un token filtrado tenga valor limitado. Pero forzar al usuario a re-loguear cada 15 minutos es mala UX, así que OAuth 2.0 introduce refresh tokens — cadenas opacas de vida larga que se intercambian en el endpoint /token por nuevos tokens de acceso. El refresh token suele guardarse en cookie httpOnly y solo se envía al servidor de autenticación. Buenas prácticas: rotar refresh tokens en cada uso (RFC 6749bis), revocar toda la familia si un token se repite (detección de reúso), vincular refresh tokens al cliente (PKCE), y guardarlos hasheados en servidor para que una fuga de BD no los exponga. Clientes públicos (SPA, apps móviles) deben usar el flujo PKCE. Los refresh tokens son el objetivo de alto valor — protéjalos como contraseñas.

¿Cuál es la diferencia entre JWT, JWS, JWE y JWK?

Son cuatro especificaciones relacionadas pero distintas en la familia JOSE (JSON Object Signing and Encryption). JWS (RFC 7515) es una estructura JSON firmada — lo que la gente suele llamar "JWT." JWE (RFC 7516) es una estructura encriptada con cinco partes (header.encryptedKey.iv.ciphertext.tag) donde el payload está oculto, no solo firmado. JWT (RFC 7519) es un formato de payload (claims) que puede envolverse en JWS o JWE. JWK (RFC 7517) es la representación JSON de una clave criptográfica, y JWKS es un conjunto — normalmente publicado en /.well-known/jwks.json por proveedores de identidad. Use JWS cuando el payload no es sensible (solo firmado para integridad), use JWE cuando el payload deba ser confidencial (p. ej., contiene PII). La mayoría de flujos OAuth usan JWS, no JWE.

¿Qué información debo evitar poner en un payload JWT?

Los payloads JWT están codificados en Base64URL, NO encriptados — cualquiera con el token puede leer cada claim. Nunca ponga contraseñas, números de seguridad social, datos de tarjetas, secretos de API o cualquier PII sujeta a GDPR/HIPAA/PCI en un payload JWT salvo que use encriptación JWE. Evite también cantidades grandes de datos: cada petición lleva el token completo en la cabecera Authorization, así que payloads inflados desperdician ancho de banda en cada llamada API. Mantenga claims en identificadores y scopes de autorización (ID usuario, roles, expiración). Para búsquedas sensibles, guarde los datos en servidor con clave sub. Evite también poner datos de usuario mutables (nombre, email) que puedan cambiar — el JWT cacheado mostrará valores obsoletos hasta expirar. El token es una prueba de capacidad, no un perfil de usuario.

Mi API rechazó un JWT, ¿es la firma o los claims de tiempo?

Son las dos clases de fallo distintas y conviene comprobarlas por separado. Primero los claims de tiempo (NumericDate de RFC 7519, segundos Unix en UTC): exp implica rechazar el token cuando now > exp; nbf implica rechazarlo mientras now < nbf (el token está emitido pero «aún no activo», causa real de fallos intermitentes justo tras la emisión o por desfase de reloj); iat indica cuándo se emitió y un valor muy en el futuro suele señalar un firmante mal configurado o un reloj desfasado. Esta herramienta evalúa los tres en cada decodificación y muestra PASA/FALLA por claim más una insignia agregada «Token temporalmente válido: SÍ/NO». Segundo, la firma: pega tu secreto HMAC y la herramienta verifica HS256/384/512 en el navegador vía Web Crypto. Si el veredicto temporal es SÍ y la firma es VÁLIDA, el rechazo está en otra parte: normalmente aud que no coincide con tu servicio, iss fuera de tu lista permitida, o un alg que el servidor no acepta. Un token puede estar bien firmado y aun así ser rechazado correctamente porque nbf no ha pasado; separar ambos es el camino más rápido a la causa raíz.