Générateur de JWT
Signez votre propre JSON Web Token pour tester un point d’accès, avec les douze algorithmes d’un vrai émetteur — et sans que la clé quitte jamais votre navigateur.
Signez votre propre jeton pour tester un point d’accès. Tout est calculé dans cette page.
La clé et le jeton obtenu restent dans votre navigateur : rien n’est envoyé nulle part, et rien de tout cela ne figure dans un lien partagé.
Vérifiez ce jeton dans votre propre code. L’extrait suit l’algorithme indiqué dans l’en-tête.
Créer un JSON Web Token signé
L’essentiel du travail sur les jetons consiste à les lire, ce que fait le décodeur de JWT. Parfois il faut l’inverse : un jeton qui n’existe pas encore, pour voir comment un service y réagit. Une API de préproduction qui refuse tout, un middleware en cours d’écriture, une donnée de test qui doit expirer dans cinq minutes — tous demandent un jeton que vous maîtrisez, et c’est celui que cette page signe.
Elle s’ouvre sur l’onglet Créer un jeton. Tout ce qui s’y trouve — le menu d’algorithmes, la charge utile, la clé — est assemblé et signé par votre propre navigateur via crypto.subtle.sign. Aucune requête n’est envoyée à un serveur, donc la clé que vous collez reste aussi privée que l’onglet dans lequel elle est saisie.
Ce que contiennent finalement l’en-tête et la charge utile
L’en-tête est écrit pour vous : l’algorithme choisi et typ: "JWT", plus un kid si vous remplissez ce champ. L’identifiant de clé compte quand le service destinataire détient plusieurs clés et en choisit une par son nom ; laissez le champ vide et l’en-tête garde deux champs.
La charge utile vous appartient. Deux claims non : la signature horodate toujours iat à l’instant présent et fixe exp depuis le menu Expire dans — cinq minutes, une heure, un jour, trente jours, ou rien du tout. Quand le jeton apparaît, la zone de charge utile est réécrite avec exactement ce qui a été signé : les horodatages affichés sont donc bien ceux qu’il contient. Si ces deux claims sont au cœur de votre test, le vérificateur d’expiration explique comment un serveur les lit.
Choisir l’algorithme
Les douze algorithmes se rangent en deux familles, et la différence n’est pas la solidité mais qui doit détenir la clé.
| Famille | Clé à coller | À utiliser quand |
|---|---|---|
| HS256 / HS384 / HS512 | Un secret partagé, en texte ou en Base64 | Un même service émet ses jetons et les vérifie |
| RS256 / RS384 / RS512 | Clé privée PKCS#8 (PEM) ou JWK | Plusieurs services vérifient ; ils ne voient que la moitié publique |
| PS256 / PS384 / PS512 | La même clé privée RSA | RSA avec le remplissage PSS plus récent, si le destinataire le demande |
| ES256 / ES384 / ES512 | Une clé privée EC, P-256 / P-384 / P-521 | Vous voulez des signatures courtes et de petites clés |
HS256 est proposé par défaut parce que c’est en général ce que l’on teste : un secret dans une variable d’environnement, un seul service des deux côtés. Dès que plusieurs services doivent contrôler le jeton, un algorithme à clé publique est la meilleure forme, car il n’oblige jamais à confier au vérificateur de quoi émettre des jetons.
À quoi sert un jeton généré — et à quoi il ne sert pas
Un jeton signé ici est un vrai jeton : collez-le dans le décodeur ci-dessus, appuyez sur Vérifier avec la même clé et la signature tient, parce que la page la calcule comme n’importe quelle bibliothèque. Il sert donc pour des jeux de test, pour reproduire un bug avec un jeton expiré ou pas encore valide, et pour savoir si votre middleware valide vraiment aud ou se contente de le lire.
Ce qu’il n’est pas : une porte d’entrée. Un jeton n’est accepté que par un service qui détient la clé correspondante ; en signer un avec votre propre secret ne prouve donc rien à personne. C’est tout l’objet de la signature, et c’est pourquoi la différence entre un jeton et un cookie de session revient à savoir qui doit stocker quoi.
Clés, formats et les erreurs qu’ils provoquent
Pour la famille HS, collez le secret tel quel, ou cochez Le secret est en Base64 si votre configuration le stocke encodé : la même chaîne, brute ou décodée, donne deux signatures totalement différentes, ce qui explique souvent qu’un jeton passe d’un côté et échoue de l’autre.
Pour RS, PS et ES, le navigateur accepte un PEM PKCS#8 — le bloc qui commence par -----BEGIN PRIVATE KEY----- — ou un JWK, la forme JSON dans laquelle un jeu de clés est distribué. Un ancien bloc -----BEGIN RSA PRIVATE KEY----- est en PKCS#1 et doit d’abord être converti. Si vous collez une clé publique par erreur, la page vous le dit au lieu d’échouer sur un message obscur, car une clé publique peut vérifier une signature mais jamais en produire une.