Firmar JWT

Funciones

• 13 algoritmos: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 y EdDSA
• ⚠️ El aviso de «no pegues una clave de producción en una página web» va al principio del resultado, no escondido en las preguntas frecuentes
• ⚠️ Un token sin `exp` se señala como que nunca caduca: olvidarlo es emitir una credencial que no se puede revocar por tiempo
• Rellena `iat` y `exp` automáticamente (`iat` solo si lo dejaste fuera, para no sobrescribir una hora que querías construir)
• Validez de 5 minutos a un año, o ninguna si escribes tú el `exp`
• ⚠️ Las claves privadas deben ser PKCS#8; PKCS#1 y SEC1 se detectan y vienen con la conversión `openssl pkcs8 -topk8`
• ⚠️ ES512 usa la curva P-521 (no existe «P-512»)
• ⚠️ Las firmas ES* se emiten como r‖s de anchura fija de JWS, no con la codificación DER que suele usar ECDSA
• ⚠️ PS* usa la longitud de sal que manda JOSE (la del hash), no la que pone por defecto la API del navegador
• El encabezado y el payload se pueden copiar enteros
• Todo se ejecuta en tu navegador; la clave no se sube

Cómo se usa

1. Escribe el payload JSON en el área de texto (para una clave privada, añade una línea `---` y pega el PEM debajo)
2. Elige un algoritmo; un secreto HS* puede ir directo en el campo de opciones
3. Elige una validez; el resultado da el JWT, el encabezado, el payload y la firma

Preguntas frecuentes

¿Por qué me avisas de no firmar aquí tokens de producción?

Porque esto es una página web y no puedes auditar si hace solo lo que dice, mientras que tu propio script sí puedes auditarlo. Esta página realmente se ejecuta en local y no sube nada, pero «créeme» y «lee tú el código» no son lo mismo, sobre todo cuando lo que pegas es una clave de firma de producción. Para tokens de prueba o para trastear con una API, es cómodo. Para producción, usa un comando o una biblioteca que corra en tu propia máquina.

¿Por qué la clave va en el área de texto y no en una opción?

Porque una clave privada PEM tiene necesariamente varias líneas (encabezado, cuerpo base64, pie) y la opción genérica de «texto» se dibuja como un campo de una sola línea en el que físicamente no cabe. Por eso el convenio es una línea que contenga solo `---`: el payload arriba y la clave abajo. Un secreto HS* es una sola línea de base64 y cabe en el campo de opciones, así que las dos vías funcionan.

¿Por qué me rechaza la clave privada RSA?

Casi siempre es un problema de formato. La API criptográfica del navegador solo acepta PKCS#8 (`-----BEGIN PRIVATE KEY-----`), mientras que muchas herramientas exportan PKCS#1 (`-----BEGIN RSA PRIVATE KEY-----`), y las claves EC tienen una tercera forma, SEC1 (`-----BEGIN EC PRIVATE KEY-----`). Las tres son PEM y se parecen mucho, pero la estructura interna es distinta. Pasar el base64 de PKCS#1 directo a la API no informa de un error de formato: lanza un error sin causa discernible. Por eso aquí se detectan, con `openssl pkcs8 -topk8 -nocrypt -in old.pem -out new.pem` como solución.

¿Cómo verifico el token que acabo de firmar?

Para HS*, calcula el mismo HMAC con el mismo secreto y compara. Para RS, PS, ES y EdDSA, dale al verificador la clave pública: ese es el sentido de los algoritmos asimétricos, que quien verifica no necesita una clave capaz de firmar. Ojo: las firmas ES* en JWS son r‖s de anchura fija, no DER, y algunas bibliotecas necesitan que se declare esa codificación, o la verificación fallará sin causa evidente.

¿Qué pasa si no hay exp?

Casi todas las bibliotecas de verificación tratan un token sin `exp` como válido para siempre. No es un agujero de la especificación: `exp` es opcional y omitirlo significa que no caduca. Así que olvidarlo al firmar emite una credencial que nunca expira, y además se parece exactamente a un token normal. Esta herramienta lo dice en el resultado.