Generador JWT
Arma el header y los claims, introduce el secreto y copia un token JWT firmado con HS256, HS384 o HS512. Sirve para probar login, perfiles de acceso y caducidad sin depender del proveedor de identidad.
Solo para pruebas. Usa un secreto de pruebas o el aleatorio que se genera aquí, nunca el secreto de producción. La firma se hace en tu navegador y no se envía nada a ningún servidor.
Algoritmo
HMAC con SHA-256, SHA-384 o SHA-512. Quien valida el token necesita el mismo secreto.
Perfil de prueba
El alg del header sigue al algoritmo elegido.
Añadir claim
Token generado
El token aparece aquí en cuanto el header, el payload y el secreto sean válidos.
¿Recibiste un token y quieres ver qué lleva dentro?
¿Cómo usar el Generador JWT?
Arma los claims
Elige un perfil de prueba o edita el JSON del payload. Los atajos añaden exp relativo, iat, jti y otros claims comunes.
Introduce el secreto
Usa el mismo secreto configurado en tu backend de pruebas o genera uno aleatorio con el tamaño adecuado para el algoritmo.
Mira el token
El token se firma con cada cambio, sin botón. El resumen muestra cuándo caduca.
Copia y prueba
Copia el token o el header Authorization listo y úsalo en Postman, en curl o en un test automatizado.
Para qué generar un JWT de prueba
No siempre es práctico iniciar sesión en el proveedor de identidad para cada escenario de prueba. Con un token generado aquí pruebas la API con el perfil que quieras, incluso casos difíciles de reproducir, como un token ya caducado o sin un rol. Funciona cuando tu backend de pruebas valida el token con un secreto HMAC que conoces.
Escenarios que merecen un token de prueba
- Un admin y un usuario común con el mismo sub, para comprobar que la ruta bloquea a quien no tiene el rol
- Un token caducado, para asegurarte de que la API responde 401 y el front pide un token nuevo
- Un token con nbf en el futuro, para probar el rechazo de un token que todavía no vale
- Un token sin el claim roles o con un scope incompleto, para probar la respuesta 403
- Un token con el aud de otra API, para confirmar que la API no acepta tokens ajenos
- Una firma hecha con otro secreto, para confirmar que la API rechaza un token manipulado
HS256, RS256 y ES256: en qué se diferencian
HS256 usa un secreto compartido: el mismo valor firma y verifica, así que quien valida también puede emitir tokens. RS256 usa un par de claves RSA: el proveedor firma con la clave privada y las APIs verifican con la pública, que se puede publicar. ES256 hace lo mismo con curvas elípticas, con claves y firmas mucho más pequeñas. Proveedores como Keycloak, Auth0 y Cognito firman con RS256 por defecto.
Este generador solo firma con HMAC a propósito. Firmar RS256 o ES256 obligaría a pegar una clave privada en el navegador, y una clave privada no debe salir del servidor que emite los tokens. Para probar una API que valida RS256, obtén el token en el propio entorno de pruebas del proveedor.
Cómo se calcula la firma HMAC
El generador codifica el header y el payload en base64url, los une con un punto y calcula el HMAC de ese texto con el secreto. El resultado, también en base64url, pasa a ser la tercera parte del token. Por eso cualquier cambio en el payload, aunque sea un espacio, produce otra firma, y el backend rechaza un token modificado si no se conoce el secreto.
Tamaño del secreto
La RFC 7518 pide un secreto al menos tan largo como la salida del hash: 32 bytes para HS256, 48 para HS384 y 64 para HS512. Un secreto como password123 firma sin problemas, pero se puede descubrir por fuerza bruta a partir de un token capturado. El botón Generar aleatorio crea uno con el tamaño mínimo para el algoritmo elegido.
Cómo enviar el token en una petición
Lo más habitual es el header Authorization con el prefijo Bearer. El botón Copiar Authorization copia la línea lista. Con curl queda así:
curl -H "Authorization: Bearer TU_TOKEN" https://api.pruebas.ejemplo.com/pedidosPreguntas Frecuentes sobre el Generador JWT
Dudas habituales de quien genera tokens JWT para pruebas.