La primera vez que tuve que depurar un flujo de autenticación roto en una API de Laravel, perdí una tarde porque no podía producir un token en el que confiara. El middleware seguía devolviendo 401 y no podía decir si el error estaba en mi código de verificación o en el token que lo estaba alimentando. Necesitaba un JWT bueno y conocido con un específico sub, un vencimiento específico y un secreto que controlé, para poder aislar un lado del problema. Copiar un token aleatorio de una respuesta de Stack Overflow hizo lo contrario de ayuda, porque estaba firmado con un secreto que no tenía.
Ese es el vacío que llena un generador JWT. No es un servicio de firma de producción. Es una herramienta de banco por el momento en que estás construyendo o probando algo que consume JSON Web Tokens y necesitas uno válido a pedido, con las afirmaciones exactas y el secreto exacto que elijas. Esta guía cubre cómo funciona la herramienta, cómo se ensambla y firma un JWT y los casos prácticos en los que generar un token a mano le ahorra tiempo real.
TL;Dr: Un generador JWT convierte una carga útil JSON más un secreto en un token firmado. Pegue sus reclamos, elija HS256, HS384 o HS512, ingrese el secreto y copie el token. El Generador JWT firma con la API de criptomonedas web del navegador, por lo que la carga útil y el secreto nunca salen de su máquina. Úselo para crear tokens de prueba con un conocido
sub, un vencimiento determinado o un vencimiento deliberadoexppara ejercitar sus rutas de error API's. Para leer un token, emparéjelo con Decodificador JWT.
¿qué es un JWT y qué produce el generador?
Un token web JSON es una forma compacta y segura para URL de representar un conjunto de afirmaciones. La estructura está definida por RFC 7519 y el formulario firmado, que es lo que casi todo el mundo quiere decir con "a JWT," es una firma web JSON según lo define RFC 7515. Un token firmado tiene tres partes unidas por puntos: header.payload.signature.
El encabezado es un pequeño objeto JSON que nombra el algoritmo de firma y el tipo de token, algo así como { "alg": "HS256", "typ": "JWT" }. La carga útil es un objeto JSON de reclamaciones: de quién se trata el token, cuándo expira y qué campos personalizados agrega su aplicación. Tanto el encabezado como la carga útil están codificados en Base64url, que es base64 ordinaria con dos sustituciones de caracteres y sin relleno, exactamente como especifica RFC 7515. La firma es un hash con clave calculado sobre las dos primeras partes.
El generador ensambla los tres. Usted suministra la carga útil y el secreto, construye el encabezado, codifica ambos segmentos, calcula la firma y los une. La salida es una cadena que puedes colocar directamente en un Authorization: Bearer encabezado, un elemento de prueba o a curl comando.
Una cosa que vale la pena ser contundente desde el principio: un JWT firmado está codificado, no cifrado. Cualquiera que tenga el token puede decodificar la carga útil de Base64url y leer todos los reclamos que contiene. La firma no oculta el contenido. Sólo demuestra que el contenido no fue cambiado por alguien sin la clave. Nunca coloque una contraseña, una clave API ni nada más que no le muestre al usuario dentro de una carga útil JWT.
¿Cómo funciona la firma?
Para la familia HMAC, que es con lo que firma esta herramienta, la firma es HMAC(secret, header + "." + payload). HMAC es una construcción hash con clave definida por RFC 2104, y la especificación JWA, RFC 7518, asigna los tres nombres de algoritmos JWT: HS256 usa HMAC con SHA-256, HS384 usa SHA-384 y HS512 usa SHA-512.
La propiedad importante es la simetría. El mismo secreto crea y verifica la firma. Cuando su servidor recibe un token, lo vuelve a calcular HMAC(secret, header + "." + payload) sobre los dos primeros segmentos recibidos y comprueba que el resultado sea igual al segmento de firma. Si se modificó un solo byte de la carga útil, el hash recalculado no coincidirá y la verificación falla. Esa es toda la garantía de integridad.
Debido a que es simétrico, el secreto es todo el juego. Cualquiera que tenga el secreto puede crear tokens válidos para su sistema, razón por la cual el generador ejecuta la firma en su navegador a través de la API Web Crypto y nunca transmite el secreto a ninguna parte. Puede confirmarlo abriendo la pestaña Red de su navegador ' mientras genera un token: no hay ninguna solicitud. Esto importa más de lo que parece, porque pegar un secreto de firma de producción en vivo en una herramienta web aleatoria que los teléfonos domésticos entregarían las claves de su autenticación.
RS256 y ES256, los algoritmos asimétricos, funcionan de manera diferente: una clave privada firma y una clave pública coincidente verifica. Esas son las opciones correctas cuando muchos servicios necesitan verificar tokens pero solo uno debería poder emitirlos. Esta herramienta deliberadamente no los ofrece, porque firmar con ellos significa pegar una clave privada en una página web, y ese es un hábito que vale la pena nunca comenzar.
Cómo utilizar el generador JWT
Paso 1: escribe la carga útil
Ingrese sus reclamos como un objeto JSON. Un ejemplo mínimo es { "sub": "1234567890", "role": "admin" }. los sub el asunto es el reclamo, generalmente una identificación de usuario. Puede agregar cualquier campo personalizado que lea su aplicación, como role, scope, tenant_id, o email. La herramienta mantiene todo lo que pones aquí exactamente como está escrito.
Paso 2: agregue las reclamaciones de tiempo
Salida emitida en y los sellos de herramientas iat con la hora actual de Unix. Establezca un vencimiento en segundos para agregar un exp reclamo calculado como ahora más ese desplazamiento. Para un token de acceso de quince minutos, ingrese 900. Para un token de una hora, ingrese 3600. Estas son las afirmaciones a las que se reducen la mayoría de los errores de autenticación, por lo que calcularlos correctamente, en segundos desde la época en lugar de milisegundos, elimina un error común.
Paso 3: elige el algoritmo y el secreto
Elija HS256 a menos que tenga una razón para usar HS384 o HS512. Ingrese el secreto de firma en el campo. Luego elija cómo se interpreta el secreto: el texto sin formato utiliza los bytes UTF-8 de lo que escribe, mientras que base64url y hexadecimal decodifican la cadena primero en bytes sin formato. Esta elección es importante porque muchos sistemas almacenan el secreto que ya está codificado en base64, y si introduce la cadena codificada como texto sin formato, producirá una firma que no coincide.
Paso 4: copie el token
El JWT firmado aparece junto con una vista previa decodificada del encabezado y la carga útil para que pueda confirmar cada reclamo antes de usarlo. Cópialo y pégalo donde lo necesites.
¿Por qué generar un token a mano?
Probando su camino feliz API '
Cuando escribe middleware que valida JWT, necesita un token que su código debería aceptar. Genere uno firmado con el mismo secreto que utiliza su verificador, con un válido exp, y confirme que la solicitud devuelve 200. Si no es así, el error está en su lógica de verificación, no en el token. Este único paso de aislamiento es la razón por la que busco la herramienta con más frecuencia.
Probando las rutas de falla
Una API sólida rechaza los tokens correctos por las razones correctas. Genere un token con un exp ya en el pasado para confirmar que devuelve el error de token caducado correcto. Genera uno con a nbf en el futuro para probar la ruta aún no válida. Genere uno firmado con el secreto equivocado para confirmar que se ejecuta su verificación de firma. Estos casos negativos son los que se envían sin probar y un generador los convierte en un trabajo de treinta segundos.
Reproducir un error de un usuario específico
El soporte informa un problema que solo ocurre para cuentas con un rol particular. Genera un token con ese exacto role reclamo y el usuario afectado's sub, y puede reproducir la solicitud localmente sin tocar los datos de producción ni pedirle al usuario su token portador real, lo que nunca debería hacer de todos modos.
Siembra de desarrollo local
Los nuevos desarrolladores de un equipo necesitan un token de trabajo para acceder a los puntos finales protegidos mientras aún se está construyendo la autenticación frontal. Un token generado y firmado con el secreto de desarrollo local los desbloquea inmediatamente.
HS256 vs HS384 vs HS512: ¿cuál deberías usar?
| algoritmo | Hash | Tamaño de la firma | Longitud mínima de la llave | Cuándo usar |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 bytes | 32 bytes | El predeterminado. Rápido, ampliamente compatible, seguro para casi todos los usos |
| HS384 | SHA-384 | 48 bytes | 48 bytes | Cuando una política o norma requiera SHA-384 |
| HS512 | SHA-512 | 64 bytes | 64 bytes | Contextos de alta seguridad, o cuando ya estás estandarizado en SHA-512 |
La respuesta práctica es HS256 a menos que algo externo requiera lo contrario. RFC 7518 requiere que la clave sea al menos tan larga como la salida hash, por lo que 32 bytes para HS256, 48 para HS384 y 64 para HS512. El generador advierte cuando su secreto decodificado es más corto que el mínimo, porque una clave corta debilita la firma independientemente del nombre del algoritmo. Un algoritmo más largo y con números más altos no fija un secreto débil; lo que importa es un secreto aleatorio de longitud adecuada.
Errores comunes y cómo evitarlos
El más frecuente es una discrepancia secreta causada por la codificación. Su marco almacena el secreto como base64, pega la cadena base64 como texto sin formato y ahora los bytes clave difieren de lo que usa su verificador. Las firmas nunca coinciden y persigues un error fantasma. Arreglalo eligiendo la codificación secreta correcta en la herramienta para que los bytes de clave sin formato sean idénticos en ambos lados.
El segundo es confuso de segundos y milisegundos. Las reclamaciones de tiempo registradas en RFC 7519 se miden en segundos desde la época de Unix. JavaScript's Date.now() devuelve milisegundos. Si calculas exp tú mismo y olvídate de dividir por 1000, tu token parece caducar dentro de cincuenta mil años, lo que algunos verificadores estrictos rechazarán. Dejar que el generador calcule las afirmaciones evita esto por completo.
El tercero es tratar la carga útil como privada. No lo es. Si se siente tentado a almacenar un secreto en un reclamo, deténgase. Cualquiera que tenga el token puede leerlo. Almacene sólo lo que se sienta cómodo con la visión del titular del token y mantenga datos genuinamente secretos en el servidor.
Donde los JWT encajan junto con otras herramientas
Una vez que haya generado un token, el siguiente paso natural es volver a leerlo. El Decodificador JWT divide cualquier token en su encabezado y carga útil y marca un vencimiento exp, que es como confirmas que el generador produjo lo que pretendías. Si también estás generando secretos, el generador de hash calcula los hashes SHA del lado del cliente y el generador de contraseñas produce el tipo de cadena aleatoria larga que convierte en secreto un buen HMAC en primer lugar. Si desea comprender la URL Base64 paso a mano, el Codificador/decodificador Base64 muestra la misma transformación reversible que convierte el encabezado y la carga útil en su forma codificada. Y cuando necesita un identificador aleatorio para colocarlo en a sub investigaciones operacionales jti reclamación, la generador de UUID te da uno en el formato correcto.
Para obtener una imagen más amplia de por qué las herramientas basadas en navegadores mantienen el material confidencial fuera de los servidores de terceros, el Privacidad de datos en herramientas en línea la guía explica el modelo del lado del cliente y el Kit de herramientas para desarrolladores web resume las utilidades que combinan bien con el trabajo de tokens.
¿Cómo verifica un servidor el token que genera?
Ayuda saber qué sucede en el otro lado, porque explica por qué el secreto y las afirmaciones tienen que ser exactamente correctos. Cuando su API recibe un token, una biblioteca como jsonwebtoken, josé o PyJWT hace tres cosas en orden. Divide el token en los puntos y Base64url decodifica el encabezado para leer alg. Recalcula la firma header.payload usando el secreto configurado y lo compara, byte por byte, con el segmento de firma. Y comprueba las reclamaciones registradas: es exp en el pasado, lo es nbf en el futuro, lo hace iss y aud coincida con lo que espera la API.
Cada una de esas comprobaciones se asigna a algo que el generador le permite controlar. Si la verificación falla en la firma, el secreto o su codificación difiere entre los dos lados. Si falla en exp, el token ha caducado, lo que es posible que haya provocado a propósito probar esa ruta. Si falla alg, generaste un token con un algoritmo que el verificador no está configurado para aceptar, lo cual en sí mismo es algo útil de descubrir. Generar tokens con variaciones deliberadas es la forma en que se asignan exactamente qué verifica las fuerzas de su API y cuáles omite silenciosamente.
Unas palabras sobre el alg encabezado específicamente. RFC 7515 define none como algoritmo válido para un token sin firmar, las primeras bibliotecas confiarían en un token que reclamara alg: none y omita la verificación por completo. Ésa es la vulnerabilidad JWT clásica. Las bibliotecas modernas lo rechazan de forma predeterminada, pero el generador ofrece none opción precisamente para que pueda activar un token sin firmar en su API y confirmar que dice que no. Si su API alguna vez acepta uno, ha encontrado un error grave.
¿cómo se deben manejar los secretos y el almacenamiento de tokens?
El secreto con el que firma merece el mismo cuidado que una contraseña de base de datos. Un buen secreto de HMAC es una cadena larga y aleatoria, no una frase memorable, porque la seguridad de HMAC depende de que la clave sea inadivinable. Generar uno con una herramienta de contraseña y almacenarlo en la configuración de su entorno, nunca en el control de origen, es la base. Cuando lo rotas, recuerda que cada token firmado con el antiguo secreto deja de ser válido en el momento en que cambia el verificador, razón por la cual los sistemas de producción generalmente admiten más de un secreto válido durante una ventana de rotación.
Del lado del cliente, donde almacena el token terminado importa tanto como cómo lo firma. Un token en localStorage es legible por cualquier JavaScript en la página, por lo que una única falla en las secuencias de comandos entre sitios le otorga a un atacante una credencial válida. Un httpOnly, Secure, SameSite la cookie es invisible para los scripts, lo que cierra ese camino a costa de necesitar protección CSRF. El patrón común es un token de acceso de corta duración que se guarda en la memoria y un token de actualización de mayor duración en un archivo httpOnly cookie. Nada de esto cambia la forma en que genera un token, pero es el contexto lo que hace que el uso de un token generado sea seguro en lugar de un pasivo.
preguntasrán el
¿cómo genero un JWT?
Pegue sus reclamos como un objeto JSON, elija un algoritmo de firma como HS256 e ingrese el secreto. La herramienta base64url codifica el encabezado y la carga útil, calcula la firma HMAC y devuelve el token terminado para que lo copie. Todo se ejecuta en su navegador.
¿qué algoritmos de firma son compatibles?
HS256, HS384 y HS512, la familia HMAC, además de "none" opción para pruebas. RS256 y ES256 no se ofrecen deliberadamente porque firman con una clave privada, y es mejor evitar pegar una clave privada en una página web como riesgo de seguridad.
¿Mi secreto se envía a un servidor?
No. La firma se ejecuta completamente en su navegador a través de la API Web Crypto, por lo que el secreto y la carga útil nunca salen de su dispositivo. Puede confirmar esto en la pestaña Red DevTools y la herramienta sigue funcionando sin conexión una vez cargada.
¿Cómo configuro que el token caduque?
Ingrese un vencimiento en segundos y la herramienta agregará un exp reclamo igual al tiempo actual más tantos segundos. Para un token de quince minutos ingrese 900. Deje el campo vacío para omitir exp completamente.
¿Por qué el secreto debería tener al menos 32 bytes?
RFC 7518 requiere una clave HMAC al menos tan larga como la salida hash, que es 32 bytes para HS256, 48 para HS384 y 64 para HS512. Un secreto más corto debilita la firma, por lo que la herramienta advierte cuando el secreto decodificado es demasiado corto.
¿puedo crear un token sin firmar?
Sí. Seleccione alg none y la herramienta producirá un encabezado.carga útil. token con una firma vacía. Esto es sólo para probar cómo su API maneja tokens sin firmar; la mayoría de las bibliotecas rechazan alg:none de forma predeterminada, y usted también debería hacerlo.
¿está cifrado un JWT generado?
No. Un JWT firmado está codificado, no cifrado: cualquiera puede codificar en base64url el encabezado y la carga útil y leer cada reclamo. La firma solo demuestra que el contenido no fue cambiado. Nunca coloque contraseñas o secretos dentro de la carga útil.
