Generador de JWT de prueba

Un JWT no está cifrado: está firmado

Esto es lo primero que hay que entender, y lo que más se malinterpreta: un JWT no oculta nada. Sus tres partes van separadas por puntos y codificadas en base64url, que no es cifrado: es una forma de escribir datos con caracteres seguros para una URL. Cualquiera que tenga el token puede leer su contenido:

const token = "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJyb2wiOiJhZG1pbiJ9.xxx";

// Leer el payload sin tener la clave, en una línea:
JSON.parse(atob(token.split(".")[1]));
// { sub: "123", rol: "admin" }

La consecuencia práctica es directa: nunca metas datos sensibles en el payload. Ni contraseñas, ni números de documento, ni datos de salud, ni nada que no quieras que vea quien intercepte el token o quien lo encuentre guardado en el navegador. La firma garantiza que el contenido no se ha modificado, no que sea secreto.

Las tres partes

Las claims con nombre reservado son las que tu librería interpreta sola, y conviene conocerlas: sub es el sujeto —normalmente el identificador de usuario—, iat el momento de emisión, exp el de expiración, nbf el momento desde el que el token es válido, iss quién lo emitió y aud para quién es. Las tres de tiempo van en segundos desde 1970, no en milisegundos: es un error clásico que produce tokens con fecha de expiración en el año 56000.

Los dos ataques que tienes que poder rechazar

1. La firma cambiada

El ataque más obvio: alguien coge un token válido, edita el payload para poner "rol":"admin", y lo reenvía. La firma ya no cuadra, y un backend correcto lo rechaza. Pero un backend que descodifica sin verificar —usando jwt.decode() en lugar de jwt.verify(), un error muy común— le concede permisos de administrador.

Esta herramienta genera exactamente ese token: elige «firma rota» y tendrás un JWT con estructura perfecta, payload legible y firma inválida. Si tu API lo acepta, has encontrado un fallo de seguridad grave.

2. El algoritmo «none»

La especificación admite "alg":"none", es decir, un token sin firma. La idea era permitir tokens ya protegidos por otro medio, pero varias librerías antiguas lo aceptaban por defecto: bastaba poner ese algoritmo y borrar la firma para que el token colara. Tu backend debe declarar qué algoritmos acepta y rechazar el resto, incluido none.

// MAL: acepta lo que diga la cabecera del propio token
jwt.verify(token, clave);

// BIEN: tú decides el algoritmo, no el atacante
jwt.verify(token, clave, { algorithms: ["HS256"] });

Hay una variante más sutil: si tu servidor acepta HS256 y RS256 a la vez, un atacante puede tomar tu clave pública —que es pública— y usarla como clave secreta de HS256. La defensa es la misma: fijar el algoritmo esperado.

Qué probar con JWT sintéticos

• Firma rota. Tu API debe devolver 401, no procesar el token. El caso número uno.
• Token expirado. Activa las fechas automáticas con expiración en el pasado y comprueba que tu cliente renueva el token en lugar de fallar con un error genérico.
• Payload con roles altos. Escribe {"rol":"admin"} y comprueba que el permiso se decide en el servidor y no confiando en lo que diga el token.
• Sin la claim exp. Un token sin expiración es válido para siempre. ¿Tu backend lo acepta? Debería tener una política.
• Payload enorme. Mete un JSON grande: el token viaja en una cabecera HTTP, y muchos servidores cortan las cabeceras por encima de 8 KB. Un token demasiado grande falla de forma muy confusa.
• Caracteres no ASCII. Pon un nombre con tildes o un emoji en el payload y comprueba que sobrevive a la codificación base64url y vuelve igual.

Tu clave no sale de aquí

La firma se calcula en tu navegador con la API de criptografía del propio navegador. No hay servidor: ni la clave secreta que escribes, ni el payload, ni el token resultante se envían a ninguna parte. Puedes comprobarlo en la pestaña Red de las herramientas de desarrollo: al pulsar «generar» no aparece ninguna petición del generador. Las que veas serán del bloque de publicidad, que es un componente independiente y no tiene acceso a lo que escribes.

Dicho esto, y por sentido común: no uses aquí la clave de producción. No porque este sitio la vaya a ver —no puede—, sino porque pegar una clave de producción en cualquier página web es un hábito que tarde o temprano sale mal. Para probar, cualquier cadena sirve.