Generador de JWT
Firma un JSON Web Token propio para probar un endpoint, con los mismos doce algoritmos que usa un emisor real y sin que la clave salga nunca de tu navegador.
Firma un token propio para probar un endpoint. Todo se calcula en esta página.
La clave y el token terminado se quedan en tu navegador: no se envían a ningún sitio y tampoco viajan en un enlace compartido.
Verifica este token en tu propio código. El fragmento sigue el algoritmo de la cabecera.
Crear un JSON Web Token firmado
Casi todo el trabajo con tokens consiste en leerlos, que es lo que hace el decodificador de JWT. A veces hace falta el camino contrario: un token que todavía no existe, para ver cómo reacciona un servicio. Una API de staging que lo rechaza todo, un middleware que estás escribiendo, un fixture de prueba que debe caducar en cinco minutos: todos necesitan un token que controles tú, y esta página lo firma.
Se abre en la pestaña Crear un token. Todo lo que hay ahí —el menú de algoritmos, el payload, la clave— lo monta y lo firma tu propio navegador mediante crypto.subtle.sign. En ningún momento se hace una petición a un servidor, así que la clave que pegas es tan privada como la pestaña en la que la escribes.
Qué acaban conteniendo la cabecera y el payload
La cabecera se escribe sola: el algoritmo que elijas y typ: "JWT", más un kid si rellenas ese campo. El identificador de clave importa cuando el servicio receptor guarda varias claves y elige una por su nombre; si lo dejas vacío, la cabecera se queda en dos campos.
El payload es tuyo. Dos claims no lo son: al firmar siempre se sella iat con la hora actual y se fija exp según el menú Caduca en —cinco minutos, una hora, un día, treinta días o nada en absoluto—. Cuando aparece el token, el cuadro del payload se reescribe con exactamente lo firmado, así que las marcas de tiempo que ves son las que lleva dentro. Si esos dos claims importan para lo que estás probando, el comprobador de caducidad explica cómo los lee un servidor.
Elegir el algoritmo
Los doce algoritmos se reparten en dos familias, y la diferencia no es la fuerza sino quién tiene que custodiar la clave.
| Familia | Clave que pegas | Úsala cuando |
|---|---|---|
| HS256 / HS384 / HS512 | Un secreto compartido, en texto o en Base64 | Un mismo servicio emite y verifica sus tokens |
| RS256 / RS384 / RS512 | Clave privada PKCS#8 (PEM) o JWK | Verifican muchos servicios; solo ven la mitad pública |
| PS256 / PS384 / PS512 | La misma clave privada RSA | RSA con el relleno PSS más moderno, si el receptor lo pide |
| ES256 / ES384 / ES512 | Una clave privada EC, P-256 / P-384 / P-521 | Quieres firmas cortas y claves pequeñas |
HS256 viene seleccionado porque suele ser lo que se está probando: un secreto en una variable de entorno y un solo servicio a ambos lados. En cuanto más de un servicio tiene que comprobar el token, un algoritmo de clave pública encaja mejor, porque al que verifica nunca hay que confiarle algo capaz de emitir tokens.
Para qué sirve un token generado, y para qué no
Un token firmado aquí es un token de verdad: pégalo en el decodificador de arriba, pulsa Verificar con la misma clave y la firma cuadra, porque la página la calcula igual que cualquier biblioteca. Eso lo hace útil para fixtures, para reproducir un fallo con un token caducado o aún no válido, y para averiguar si tu middleware valida aud de verdad o solo lo lee.
Lo que no es, es una puerta de entrada. Un token solo lo acepta un servicio que tenga la clave correspondiente, así que firmar uno con un secreto propio no le demuestra nada a nadie. De eso trata la firma, y por eso la diferencia entre un token y una cookie de sesión se reduce a quién tiene que guardar qué.
Claves, formatos y los errores que provocan
Para la familia HS, pega el secreto tal cual, o marca El secreto está en Base64 si tu configuración lo guarda codificado: la misma cadena en crudo y decodificada produce firmas completamente distintas, que es una causa habitual de que un token valga en un sitio y falle en otro.
Para RS, PS y ES el navegador acepta un PEM PKCS#8 —el bloque que empieza por -----BEGIN PRIVATE KEY-----— o un JWK, la forma JSON en la que se reparten las claves. Un bloque antiguo -----BEGIN RSA PRIVATE KEY----- es PKCS#1 y hay que convertirlo antes. Si pegas una clave pública por error, la página te lo dice en lugar de fallar con un mensaje críptico, porque una clave pública puede comprobar una firma pero nunca crearla.