Generador de JWT

El generador admite HS256, HS384 y HS512 con un secreto compartido; RS256, RS384, RS512, PS256, PS384 y PS512 con una clave privada RSA; ES256, ES384 y ES512 con una clave privada EC de tipo P-256, P-384 o P-521; y EdDSA con una clave privada Ed25519. El algoritmo elegido se escribe en el encabezado alg y typ siempre se establece como JWT.

Introduzca un objeto JSON con sus declaraciones, por ejemplo, sub, name, iss, aud o cualquier miembro personalizado. Se rechazan las matrices, las cadenas y otros valores que no sean objetos, porque una carga útil JWT debe ser un objeto JSON. El orden de las declaraciones y sus valores se conservan exactamente como los escribió.

Para HS256, HS384 y HS512, el secreto se usa como texto UTF-8 después de quitar los espacios en blanco iniciales y finales. Si el secreto es binario, péguelo como JWK, por ejemplo {"kty": "oct", "k": "..."}, con los bytes en base64url; se usarán los bytes decodificados. Se rechazan las claves PEM para los algoritmos HMAC, porque usar una clave pública como secreto HMAC es un error clásico.

RFC 7518 recomienda una clave al menos tan larga como la salida del hash: 32 bytes para HS256, 48 para HS384 y 64 para HS512. La herramienta firma con secretos más cortos para que pueda reproducir tokens de prueba, pero los secretos de producción deben ser valores aleatorios largos, por ejemplo, generados con el Generador de contraseñas.

Pegue una clave privada PEM sin cifrar en formato PKCS #8 (BEGIN PRIVATE KEY), PKCS #1 (BEGIN RSA PRIVATE KEY) o SEC1 (BEGIN EC PRIVATE KEY), o una JWK privada que contenga el miembro d. No se leen archivos PEM cifrados ni claves privadas OpenSSH. La clave debe ser compatible con el algoritmo, así que ES384 necesita una clave P-384 y las claves RSA deben tener al menos 2048 bits.

Cuando está activada la opción de fecha de emisión, iat se establece en la hora actual, salvo que la carga útil ya tenga una declaración iat. Cuando la caducidad es superior a 0 segundos, exp se establece en la hora actual más esa cantidad de segundos y sustituye cualquier exp de la carga útil. Si la caducidad es 0, no se añade exp y se conserva el exp de la carga útil.

Se escribe un ID de clave no vacío en el encabezado kid para que los verificadores puedan elegir la clave correcta de un JWKS. Si pega un JWKS como clave de firma, kid también selecciona qué clave del conjunto firma el token. El conversor de JWK y los generadores de claves muestran la huella digital RFC 7638, que es adecuada como kid.

Obtendrá el token compacto, el algoritmo, el ID de clave, las horas de emisión y caducidad en UTC, y el encabezado y la carga útil JSON exactos que se firmaron. Copie el token del primer bloque. Más adelante, decodifíquelo con el decodificador JWT o compruébelo con el verificador JWT.

No. El secreto o la clave privada solo se envía en la solicitud que firma el token, se usa una vez en memoria y nunca se registra ni se guarda. Aun así, prefiera claves de prueba para hacer experimentos y nunca pegue una clave de firma de producción en una herramienta web, a menos que controle el servidor.

La carga útil puede tener hasta 65,536 caracteres, la clave hasta 65,536 caracteres y kid hasta 256 caracteres. Los valores de caducidad van de 0 a 315,360,000 segundos, es decir, diez años. Las entradas más largas se rechazan con un mensaje que indica el campo.