🪪 Generador y Firmante JWT
Introduce header, payload y secret para generar un JWT firmado en tu navegador. Soporta HS256 / HS384 / HS512 vía Web Crypto API.
⚠️ Notas de Seguridad
• Los secrets se procesan en tu navegador con Web Crypto API y nunca se envían al servidor.
• Introducir secrets de producción en herramientas web no se recomienda. Úsalo para pruebas, aprendizaje y depuración.
• HS256 debe tener al menos 256 bits (32 bytes); HS512 al menos 512 bits (64 bytes).
🔗 Herramientas relacionadas
📖 Dónde se suele tropezar
Introduce una cabecera, una carga util y un secreto, y esto genera un JWT firmado en el navegador con la Web Crypto API (HS256, HS384 o HS512). Hay botones para anadir reclamaciones como iat y exp. El secreto no se envia nunca a un servidor. Hay algo que conviene entender sobre los JWT antes que nada: un JWT no es cifrado. La carga util solo esta codificada en Base64URL, y cualquiera, sin clave alguna, puede leerla. La firma garantiza unicamente que el contenido no fue alterado; no garantiza absolutamente nada sobre que no haya sido visto.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Pegar un secreto de produccion en una herramienta de navegador | Esta pagina no envia valores a ningun servidor, pero "no se transmite" y "no deja rastro" son afirmaciones distintas. La cadena que escribes existe en el DOM, puede quedar en el historial y el autorrelleno del navegador, sale en capturas de pantalla y en pantallas compartidas y es legible por cualquier extension que tengas instalada. Si la copias, acaba tambien en tu gestor de historial del portapapeles. Lo que mas se pasa por alto es el propio token generado: un JWT pegado en Slack o en un ticket para depurar sigue siendo utilizable mientras sea valido, aunque el secreto no se haya filtrado jamas, porque un JWT es un token al portador y quien lo tiene es tratado como el sujeto. | Introduce en esta pagina solo un secreto desechable. Basta con un valor del boton de generacion aleatoria: si lo que quieres es comprobar como funciona la firma, no hace falta que sea real. Si ya has pegado un secreto de produccion, hay exactamente un remedio: rotalo ahora. Dejarlo estar dando por hecho que no pasa nada te priva de toda forma de determinar mas adelante si se filtro, y un secreto HMAC se puede romper por fuerza bruta en local a partir de un unico token capturado, de modo que las palabras de diccionario y las cadenas cortas son especialmente peligrosas. Mejor aun: disena el sistema para que ningun humano llegue a ver un secreto de produccion: que se lea directamente de una variable de entorno o de un gestor de secretos, sin crear jamas una via de copiar y pegar. |
exp solo significa algo para quien verifica |
exp es solo un campo; no es un mecanismo que haga que el token deje de funcionar al llegar la hora: se convierte en caducidad unicamente porque quien verifica lee el valor y rechaza el token. De ahi salen cuatro defectos clasicos. (1) Si olvidas exp, el token vale para siempre. (2) Equivocarse de unidad: los tiempos en un JWT son segundos desde la epoca, mientras que Date.now() de JavaScript devuelve milisegundos, asi que pasarlo tal cual apunta cincuenta mil anos al futuro. (3) El desfase de reloj entre servidores hace que un token recien emitido sea rechazado por su nbf. (4) Un token emitido no se puede revocar: cerrar sesion o cambiar la contrasena no lo detiene; sigue valido hasta exp. |
Manten corto el exp de un token de acceso: de quince minutos a una hora es la recomendacion habitual. Manten la sesion de larga duracion con un token de refresco, guardado en el servidor para poder invalidarlo individualmente. Es la unica forma de atacar de frente el problema de la revocacion. Si la revocacion inmediata es un requisito, incluye un jti y manten una lista de denegacion, pero en ese momento habras renunciado a la ventaja de servidor sin estado que motivaba usar JWT, asi que comprueba si el requisito es real antes de construirlo. En el verificador, permite un margen de algunas decenas de segundos al comparar exp y nbf. Y usa siempre segundos: en JavaScript, Math.floor(Date.now() / 1000). |
Quien verifica se fia del alg del token |
El alg de la cabecera esta en un lugar que el atacante puede reescribir: una biblioteca que lo lea para decidir como verificar esta dejando que el atacante elija el metodo de verificacion. Existen dos roturas conocidas. (1) alg: none: escribe el valor que significa "sin firmar" y deja vacio el segmento de firma, y una biblioteca implementada de forma ingenua lo acepta. (2) Confusion entre RS256 y HS256: se toma un token pensado para verificarse con una clave publica RSA, se reescribe alg a HS256 y se firma usando la clave publica como secreto HMAC. Como la clave publica es publica, el atacante puede acunar tokens validos a voluntad. Ambos son errores de implementacion, no defectos del propio JWT. |
En el verificador, pasa el algoritmo como valor fijo. La mayoria de las bibliotecas aceptan un argumento como algorithms: ['HS256']: si la API te permite omitirlo, no lo omitas. El alg que lees de un token no es una entrada de la verificacion: es una de las cosas que se estan verificando. Fija la clave del mismo modo y, si rotas varias claves, selecciona por kid y hazlo siempre dentro de tu propio conjunto de claves. No olvides tampoco la fuerza del secreto: usa al menos 256 bits de aleatoriedad para HS256 y nunca una contrasena memorizable, porque un HMAC se puede verificar sin conexion tantas veces como quiera el atacante a partir de un solo token, lo que convierte los ataques de diccionario en una amenaza real. Y por ultimo, no escribas tu la biblioteca. |
No pongas secretos en la carga util. Insistimos: cualquiera puede leerla. Si metes ahi una direccion de correo, un telefono, el desglose de permisos o identificadores internos, los has publicado ante todo el que vea el token. Recuerda al disenar que cualquiera puede abrir las herramientas de desarrollo del navegador y leer el contenido de su propio token. Manten las reclamaciones al minimo y pide los detalles al servidor cuando realmente los necesites. Hay ademas muchas situaciones en las que un JWT sencillamente no es lo mas adecuado: para una aplicacion web corriente en un solo dominio, una sesion en el servidor es mas simple y permite cerrar sesion al instante. Donde el JWT se gana su sitio de verdad es en la autenticacion que abarca varios servicios, o en arquitecturas donde el verificador no puede consultar al emisor. "Es moderno" no es una razon: eligelo segun si puedes aceptar el intercambio, ausencia de estado a cambio de imposibilidad de revocar.
📖 Cómo usar
-
1
Configura algoritmo y payloadElige HS256/384/512 e ingresa los claims JSON.
-
2
Ingresa o genera el secretEscribe el secret o usa el botón Aleatorio.
-
3
Copia el JWT generadoEl JWT firmado aparece al instante.
❓ Preguntas frecuentes
¿Diferencia entre HS256, HS384, HS512?
¿Es seguro ingresar el secret de producción?
¿Soporta RS256 o ES256 asimétricos?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.