Générateur JWT

Le générateur prend en charge HS256, HS384 et HS512 avec un secret partagé, RS256, RS384, RS512, PS256, PS384 et PS512 avec une clé privée RSA, ES256, ES384 et ES512 avec une clé privée EC sur P-256, P-384 ou P-521, et EdDSA avec une clé privée Ed25519. L'algorithme choisi est inscrit dans l'en-tête alg, et typ est toujours défini sur JWT.

Saisissez un objet JSON contenant vos revendications, par exemple sub, name, iss, aud ou tout membre personnalisé. Les tableaux, chaînes et autres valeurs qui ne sont pas des objets sont refusés, car une charge utile JWT doit être un objet JSON. L'ordre et les valeurs des revendications sont conservés exactement comme vous les avez saisis.

Pour HS256, HS384 et HS512, le secret est utilisé comme texte UTF-8 après suppression des espaces blancs au début et à la fin. Si votre secret est binaire, collez-le sous forme de JWK, par exemple {"kty": "oct", "k": "..."}, avec les octets en base64url ; les octets décodés sont alors utilisés. Les clés PEM sont refusées pour les algorithmes HMAC, car utiliser une clé publique comme secret HMAC est une erreur classique.

La RFC 7518 recommande une clé au moins aussi longue que la sortie de hachage, soit 32 octets pour HS256, 48 pour HS384 et 64 pour HS512. L'outil signe avec des secrets plus courts afin que vous puissiez reproduire des jetons de test, mais les secrets de production doivent être de longues valeurs aléatoires, par exemple générées avec le générateur de mots de passe.

Collez une clé privée PEM non chiffrée au format PKCS #8 (BEGIN PRIVATE KEY), PKCS #1 (BEGIN RSA PRIVATE KEY) ou SEC1 (BEGIN EC PRIVATE KEY), ou une clé JWK privée contenant son membre d. Les fichiers PEM chiffrés et les clés privées OpenSSH ne sont pas lus. La clé doit correspondre à l'algorithme : ES384 nécessite une clé P-384 et les clés RSA doivent compter au moins 2048 bits.

Lorsque l'option d'émission est activée, iat est défini sur l'heure actuelle, sauf si votre charge utile contient déjà une revendication iat. Lorsque l'expiration est supérieure à 0 seconde, exp est défini sur l'heure actuelle plus ce nombre de secondes et remplace tout exp présent dans votre charge utile. Avec une expiration de 0, aucun exp n'est ajouté et un exp déjà présent dans votre charge utile est conservé.

Un identifiant de clé non vide est inscrit dans l'en-tête kid afin que les vérificateurs puissent sélectionner la bonne clé dans un JWKS. Si vous collez un JWKS comme clé de signature, kid sélectionne également la clé de l'ensemble qui signe le jeton. Le convertisseur JWK et les générateurs de clés affichent l'empreinte RFC 7638, qui convient bien comme kid.

Vous obtenez le jeton compact, l'algorithme, l'identifiant de clé, les heures d'émission et d'expiration en UTC, ainsi que l'en-tête et la charge utile JSON exacts qui ont été signés. Copiez le jeton depuis le premier bloc. Vous pourrez le décoder plus tard avec le décodeur JWT ou le vérifier avec le vérificateur JWT.

Non. Le secret ou la clé privée ne transite que dans la requête qui signe le jeton, est utilisé une seule fois en mémoire et n'est jamais consigné ni enregistré. Malgré cela, privilégiez les clés de test pour vos essais et ne collez jamais une clé de signature de production dans un outil web, sauf si vous contrôlez le serveur.

La charge utile peut contenir jusqu'à 65,536 caractères, la clé jusqu'à 65,536 caractères et kid jusqu'à 256 caractères. La durée d'expiration peut aller de 0 à 315,360,000 secondes, soit dix ans. Les saisies plus longues sont refusées avec un message qui indique le champ concerné.