Generador JWT gratuito

Lo que un JWT realmente es

Un JSON Web Token (JWT), pronunciado «djot», es una representación compacta y segura para URL de afirmaciones a transferir entre dos partes. El formato son tres segmentos codificados en Base64url separados por puntos: cabecera.payload.firma. La cabecera declara el tipo de token (siempre JWT) y el algoritmo de firma (habitualmente HS256, RS256 o ES256). El payload lleva las afirmaciones, un objeto JSON con campos estándar como iss (emisor), sub (sujeto), aud (audiencia), exp (tiempo de expiración como timestamp Unix), nbf (no antes), iat (emitido en), jti (ID del JWT), más cualquier afirmación específica de la aplicación que el emisor quiera incluir. La firma es la prueba criptográfica de que la cabecera y el payload no han sido alterados, producida firmando la cadena concatenada base64url(cabecera).base64url(payload) con el algoritmo y la clave declarados en la cabecera. JWT fue especificado por Michael B. Jones, John Bradley y Nat Sakimura como RFC 7519 en mayo de 2015, basándose en trabajos previos de JOSE (JSON Object Signing and Encryption, RFCs 7515 a 7520). El formato se ha convertido en la forma de token dominante en la autenticación web moderna, usada por implementaciones OAuth 2.0 / OIDC, pasarelas de API, tokens de sesión de SPA, autenticación microservicio-a-microservicio y gestión de sesión por cookie a gran escala.

La elección de algoritmo de firma, HS256 vs RS256 vs ES256

JWT admite varios algoritmos de firma registrados en el registro de algoritmos JOSE (RFC 7518). HS256 (HMAC-SHA256) es el más simple: un algoritmo simétrico donde el mismo secreto se usa para firmar y verificar. Barato de calcular, fácil de implementar y apropiado cuando el firmante y el verificador son la misma parte (por ejemplo, una sola aplicación que se emite tokens de sesión a sí misma). RS256 (RSA-SHA256) es asimétrico: la clave privada firma, la clave pública verifica. Se usa cuando emisor y verificador son partes distintas, Auth0, Okta, Google Identity Platform, Microsoft Entra ID y la mayoría de los proveedores de identidad cloud emiten JWT firmados con RS256 porque los clientes pueden verificar la firma usando un endpoint JWKS (JSON Web Key Set) publicado sin necesidad de compartir secretos. ES256 (ECDSA P-256 SHA-256) es el equivalente en curva elíptica de RS256, mismo modelo de clave pública/privada, claves mucho más cortas (256 bits frente al mínimo 2048 de RSA), verificación más rápida. EdDSA (Ed25519) es el sucesor moderno de ES256, ligeramente más rápido y con propiedades criptográficas más limpias; admitido en bibliotecas JWT recientes pero aún no universal. none es un modo «sin firma» permitido por la especificación JWT que ha causado incidentes de seguridad en varias bibliotecas cuando las implementaciones no rechazaban los tokens alg: none: la lección es que los verificadores JWT deben comprobar explícitamente que el algoritmo coincide con el esperado. Este generador usa HS256 porque solo requiere un secreto compartido en lugar de generación de claves; para uso en producción de algoritmos asimétricos, una biblioteca del lado del servidor es la herramienta adecuada.

Cuándo necesitas generar un JWT a mano

• Probar endpoints de API. Una API exige un JWT en la cabecera Authorization, para probarla a mano con curl, Postman o HTTPie, necesitas un token. Genera un JWT de prueba con la forma correcta, fírmalo con el secreto compartido de la API (en entornos de desarrollo) y usa el resultado.
• Reproducir un bug relacionado con tokens. Un usuario reporta un problema de autenticación. Reconstruye el token que habría recibido con sus afirmaciones, examina la firma, verifica la lógica de verificación de tu servicio contra un token conocido-bueno y uno conocido-malo.
• Desarrollo local sin proveedor de auth. Construyes un frontend contra una API que espera autenticación JWT, pero todavía no tienes acceso al proveedor de identidad de producción. Genera JWT de prueba con afirmaciones realistas para el desarrollo.
• Aprender el formato JWT. Decodifica un JWT, cambia una afirmación, vuelve a firmarlo, mira lo que hace tu aplicación. El bucle de depurar-trasteando es como la mayoría de desarrolladores acaban entendiendo la estructura JWT.
• Tokens internos servicio-a-servicio. Dos microservicios internos comparten un secreto y usan JWT para autenticar peticiones. El modelo HS256 de secreto compartido va bien aquí; esta herramienta puede generar los tokens a mano para probar.

Trampas de seguridad, dónde fallan los JWT

Los JWT tienen un largo historial de errores de implementación que han producido incidentes reales de seguridad. El ataque «alg: none»: las primeras bibliotecas JWT aceptaban tokens con el campo de algoritmo puesto a «none» (sin firma), permitiendo a un atacante falsificar cualquier token. Los verificadores deben imponer explícitamente el algoritmo esperado. Confusión de algoritmo: un verificador que acepta tanto RS256 como HS256 puede ser engañado usando la clave RSA pública como secreto HMAC, el atacante firma con HS256 usando la clave pública, y el verificador (mal-)verifica con HMAC usando esa misma clave pública. Los verificadores deben fijar el algoritmo esperado. Datos sensibles en el payload: las afirmaciones JWT están codificadas en Base64 pero no cifradas. Cualquiera con el token puede leer cada afirmación. Nunca pongas contraseñas, números completos de tarjeta de crédito u otros secretos en el payload. Sin expiración: los JWT sin afirmación exp son válidos para siempre. Establece siempre una expiración razonable (minutos para tokens de acceso, días para tokens de refresco). Sin revocación: los JWT son autocontenidos, una vez emitidos, siguen siendo válidos hasta exp sin importar si el usuario cierra sesión, cambia contraseña o ve su cuenta suspendida. Acepta esta limitación, mantén una lista de revocación (que rompe parcialmente el sentido del token sin estado), o usa tokens de acceso de vida corta con rotación de tokens de refresco. Almacenar en localStorage vs cookies: un JWT en localStorage es accesible a cualquier JavaScript de la página (riesgo XSS); un JWT en cookies HttpOnly no lo es (pero se envía automáticamente con peticiones cross-origin, riesgo CSRF). Ambos tienen sus pros y contras; la buena práctica moderna tiende hacia cookies HttpOnly con restricciones SameSite más tokens CSRF.

JWT vs cookies de sesión vs PASETO

JWT no es la única opción. Las cookies de sesión tradicionales guardan un ID de sesión opaco; el servidor mantiene el estado real de la sesión en una base de datos o caché. Pros: revocación trivial (borrar el registro del servidor), sin riesgo de fuga de datos de afirmaciones, sin complejidad de firma. Contras: requiere consulta al store de sesión en cada petición (latencia), más difícil de escalar entre servicios. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) es un reemplazo de JWT diseñado para evitar las trampas de confusión de algoritmo y «none», formato con versiones, sin negociación de algoritmo, firmas obligatorias, opciones de cifrado restringidas. PASETO ha ganado terreno en contextos sensibles a la seguridad pero no ha desplazado a JWT en el ecosistema más amplio. Macaroons (Google, 2014) son un formato de token más flexible con restricciones de capacidades encadenadas, pero en 2026 son esencialmente cosa de investigación. OAuth 2.1 consolida las buenas prácticas de OAuth 2.0, JWT sigue siendo el formato típico de token de acceso. La elección pragmática en 2026 sigue siendo JWT para microservicios sin estado y tokens de API, cookies de sesión opacas para apps web tradicionales renderizadas en servidor, y PASETO como alternativa moderna para proyectos nuevos que quieran defaults más fuertes.

Preguntas frecuentes

¿Puedo decodificar un JWT sin la clave secreta?

Sí. Los JWT están firmados pero no cifrados, por lo que el encabezado y la carga útil siempre se pueden leer. La clave secreta solo se necesita para verificar la firma o generar un nuevo token.

¿Es seguro pegar JWT de producción aquí?

Sí. Todo el procesamiento ocurre localmente en tu navegador. Tus tokens y claves secretas nunca se envían a un servidor ni se almacenan en ningún lugar.

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

HS256 usa una clave secreta compartida (HMAC-SHA256). RS256 usa pares de claves RSA, ES256 usa criptografía de curva elíptica. Esta herramienta admite HS256, el más común para API web.