Encodeur JWT
Construire un jeton à partir de claims, et le signer vraiment · tourne dans cet onglet, n’est jamais envoyé nulle part
En-tête
Charge utile
Clé de signature
La clé est utilisée puis abandonnée — jamais enregistrée dans ce navigateur, jamais envoyée nulle part.
Une clé de signature produit des jetons que vos systèmes accepteront. Pour une clé de production, préférez votre propre environnement.
HS256
Jeton signé
Le jeton signé apparaît ici. Rien n’est envoyé pour le produire : la signature est calculée par ce navigateur.
Comment fonctionne le Encodeur JWT
Un encodeur JWT qui produit un jeton réellement signé plutôt qu’un sosie en base64. Écrivez l’en-tête et la charge utile en JSON, choisissez un algorithme, puis collez le secret partagé pour un algorithme HS ou une clé privée PKCS#8 pour RS, PS ou ES : la signature est calculée par la WebCrypto de votre propre navigateur. L’expiration, la date d’émission et le « pas avant » s’inscrivent depuis des préréglages, si bien que vous ne convertirez plus jamais un horodatage à la main.
Écrivez l’en-tête et la charge utile en JSON, choisissez un algorithme, et le jeton est assemblé et signé au fil de la frappe. Les préréglages d’expiration inscrivent iat, exp et éventuellement nbf dans la charge utile à partir d’un même instant, de sorte que les trois ne puissent jamais diverger d’une seconde — le genre de défaut qui ne se manifeste que dans la tolérance de dérive d’horloge d’un autre système.
alg est toujours écrit à partir de l’algorithme choisi, quoi que dise votre en-tête. Ce n’est pas un confort : un en-tête annonçant un algorithme alors que la signature a été produite avec un autre est le point de départ de la vulnérabilité JWT la plus connue, et aucun jeton légitime n’est refusé de ce fait. Tout autre champ d’en-tête que vous écrivez est conservé exactement tel quel.
Les secrets HS plus courts que le condensat sont refusés par défaut — la RFC 7518 exige 32 octets pour HS256, 48 pour HS384 et 64 pour HS512, et un navigateur signera volontiers avec quatre caractères alors que le résultat se casse hors ligne en quelques secondes. La vérification peut être désactivée, car reproduire un jeton faible est parfois exactement la tâche.
La clé de signature est traitée comme le décodeur traite sa clé de vérification, et avec plus de soin encore : jamais écrite dans localStorage, jamais restaurée au rechargement, jamais dans un événement d’analytique, et aucun serveur ne pourrait la recevoir. Une clé de signature est le secret le plus dangereux d’un système qui utilise des JWT ; pour une clé de production, mieux vaut toujours produire les jetons dans votre propre environnement.
Questions fréquentes
Est-il sûr de coller une clé de signature dans cet encodeur ?
La clé est utilisée dans votre propre onglet puis abandonnée : jamais enregistrée, jamais incluse dans un événement d’analytique, et aucun serveur ne pourrait la recevoir. Cela dit, une clé de signature est le secret le plus dangereux de tout système utilisant des JWT, car quiconque la détient peut produire des jetons que vos services accepteront. Pour une clé de production, générer les jetons dans votre propre environnement reste la meilleure habitude ; cet outil est conçu pour le développement, les tests et l’apprentissage.
Avec quels algorithmes peut-il signer ?
HS256, HS384 et HS512 avec un secret partagé, et RS256/384/512, PS256/384/512 et ES256/384/512 avec une clé privée fournie en bloc PEM PKCS#8 ou en JWK privé. Il produit aussi le jeton non sécurisé `alg: none`, clairement signalé comme ne prouvant rien, car en reproduire un est la façon de vérifier que votre vérificateur le rejette.
Pourquoi mon secret court est-il refusé ?
La RFC 7518 exige une clé HMAC au moins aussi longue que le condensat : 32 octets pour HS256, 48 pour HS384, 64 pour HS512. Les navigateurs signent volontiers avec un secret de quatre caractères, et le jeton obtenu se casse hors ligne en quelques secondes. L’encodeur bloque cela par défaut et vous laisse passer outre, puisque reproduire un jeton faible est parfois exactement la tâche.
Peut-il écraser l’algorithme de mon en-tête ?
Il écrit toujours `alg` à partir de l’algorithme choisi, et c’est délibéré. Un en-tête annonçant un algorithme alors que la signature a été produite avec un autre n’est pas un jeton : c’est le point de départ de la vulnérabilité JWT la plus connue. Tout autre champ d’en-tête que vous écrivez — `kid`, `cty`, personnalisé — est conservé exactement tel quel.