Générateur JWT
Créer un JSON Web Token avec un en-tête et payload personnalisés
Qu'est-ce que JWT ?
Le générateur JWT crée des JSON Web Tokens à partir d’un header, d’un payload et de paramètres de signature. Un JWT comporte trois parties encodées en Base64URL et transporte souvent des claims comme identifiant utilisateur, rôles, expiration, émetteur ou audience entre services. L’outil est utile pour tests d’API, développement local, apprentissage, débogage et création rapide de tokens d’exemple. Un token généré n’est fiable que si gestion des clés, choix d’algorithme, expiration et validation serveur sont corrects. Les secrets ne doivent pas apparaître dans des exemples publics, les algorithmes faibles ou durées trop longues sont risqués, et les données sensibles ne doivent pas rester dans un payload non chiffré.
Comment utiliser
Processus de génération JWT
- Sélectionnez l'algorithme de signature (HS256 par défaut)
- Saisissez un secret ou cliquez sur « Generate » pour en créer un
- Modifiez le Payload JSON et utilisez les boutons d'ajout rapide pour ajouter des claims standards
- Définissez les horodatages issued at (iat) et expiration (exp)
- Cliquez sur le bouton « Generate JWT Token »
- Copiez le Token généré pour le test ou le développement
Sécurité du Token
- Utilisez des secrets robustes pour les algorithmes HMAC et protégez les clés privées pour les algorithmes RSA/ECDSA.
- Définissez des claims exp, iat, issuer et audience réalistes ; un JWT syntaxiquement valide peut tout de même être peu sûr ou rejeté par votre service.
Cas d’utilisation
Principe technique
Le générateur et le parser de JWT sont des processus inverses : le parser sépare les trois parties, le générateur les assemble. Le cœur, c'est le calcul du segment Signature. Flux d'assemblage : 1) Construire le Header JSON, par exemple {"alg":"HS256","typ":"JWT"} ; 2) Construire le Payload JSON avec les claims standard et privés ; 3) Encoder Header et Payload séparément en Base64URL pour obtenir h_b64 et p_b64 ; 4) Joindre h_b64 et p_b64 avec un point pour former input = h_b64 + '.' + p_b64 ; 5) Calculer la signature selon alg : HMAC-SHA256/384/512(secret, input) ; 6) Encoder le résultat de la signature en Base64URL ; 7) Le token final est input + '.' + sig_b64. Signature HMAC-SHA256 : on utilise le secret comme clé (>= 32 octets) et on exécute HMAC sur input. En interne, HMAC fait deux rondes de SHA-256 : il dérive d'abord les clés ipad/opad du secret, puis calcule SHA256(secret XOR ipad || msg) XOR opad. Force de la clé : la longueur du secret conditionne directement la sécurité. RFC 7518 exige des clés HS256 >= 256 bits (32 octets). En production, utilise toujours un RNG cryptographiquement sûr (par exemple crypto.randomBytes) ; n'utilise jamais de chaînes comme 'secret', 'password' ou '123456'. Pièges courants : 1) Attaque de substitution d'alg : le serveur doit valider alg strictement et ne doit pas lire alg dans le header du token pour aiguiller vers l'algorithme correspondant ; 2) Clés faibles : un secret trop court se cassera par brute force ; 3) Altération du payload : HMAC garantit l'intégrité — si un attaquant change le payload, la vérification côté serveur échoue ; 4) Fuite de token : les JWT ne sont pas révocables, une fois sortis il faut attendre leur exp. Périmètre de cet outil : seuls HS256/HS384/HS512 sont générés. Les algorithmes asymétriques comme RS256 (RSA) et ES256 (ECDSA) exigent une clé privée détenue par l'émetteur et sont produits par un service de signature backend ou un SDK dédié, pas par cette page.
- Cœur de la signature HMAC-SHA256 : HMAC(secret, header_b64 + '.' + payload_b64), produisant une signature de 256 bits encodée en Base64URL.
- La longueur de la clé HS256 doit être >= 32 octets (256 bits) ; il est recommandé de la générer avec crypto.getRandomValues ou crypto.randomBytes — les clés courtes sont vulnérables aux attaques par dictionnaire.
- Cet outil ne génère que des tokens signés en HMAC (HS256/HS384/HS512). Les algorithmes asymétriques comme RS256 ou ES256 exigent une clé privée détenue par l'émetteur et ne sont pas produits ici — utilisez un service de signature côté backend ou un SDK dédié.
- iat/exp/nbf sont tous des timestamps Unix en secondes (pas en millisecondes) ; les serveurs exigent généralement exp > now(), nbf <= now() et iat <= now().
- Attaque alg=none : maintenir une liste blanche côté serveur des algorithmes autorisés (par ex. ['HS256']) ; ne jamais choisir l'algorithme dynamiquement depuis l'en-tête du token. De nombreuses bibliothèques JWT ont historiquement autorisé alg=none par défaut — c'est une vulnérabilité connue.
- Un JWT ne peut pas être révoqué une fois émis — le seul recours est d'attendre exp. Pour une révocation active, maintenir une liste noire jti ou utiliser un access token à durée de vie courte accompagné d'un refresh token.
Exemples
Exemple HS256 de base
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Clé: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4UDurée de vie personnalisée avec iat et exp
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
La page encode l'en-tête et la charge utile en Base64URL, les joint par un point puis applique HMAC-SHA256 avec le secret partagé. Le champ Token affiche la chaîne finale en trois segments, prête à coller dans un en-tête Authorization.Claims personnalisés
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}FAQ
Le JWT est-il généré localement ?
Oui. L'en-tête, la charge utile et la signature sont calculés dans votre navigateur via la Web Crypto API. Le secret de signature ou la clé privée ne quitte jamais la page. Considérez le jeton lui-même comme une donnée susceptible d'être journalisée ou exposée, surtout si vous le collez dans un service réel.
Quels algorithmes de signature sont pris en charge ?
Cet outil génère HS256, HS384 et HS512 (HMAC avec secret partagé). Les algorithmes asymétriques comme RS256/RS384/RS512 (RSA) et ES256/ES384/ES512 (ECDSA) ne sont pas produits ici — passe par un service de signature côté backend ou un SDK dédié si ton vérificateur les exige. Évite alg=none en production : tout vérificateur sensé rejette les tokens non signés.
Que met-on dans la charge utile ?
Des claims standard comme sub, iss, aud, exp, iat, nbf ainsi que tout claim personnalisé utilisé par votre service. Gardez la charge utile petite — les JWT voyagent dans les en-têtes et grossissent à chaque requête. N'y placez jamais de mot de passe, de numéro de carte bancaire complet ou autres secrets ; la charge utile est en Base64URL, pas chiffrée.
Comment définir l'heure d'expiration ?
Définissez exp comme l'horodatage Unix (en secondes, pas en millisecondes) auquel le jeton doit cesser d'être valide. Les jetons sans exp sont techniquement légaux, mais la plupart des services en production en exigent un. Les valeurs courantes sont 5 à 60 minutes pour les jetons d'accès, 7 à 30 jours pour les jetons de rafraîchissement.
Pourquoi mon JWT généré échoue-t-il à la vérification ?
Causes courantes : alg dans l'en-tête ne correspond pas à ce qu'attend le vérificateur ; le secret/la clé est différent ; les claims de la charge utile (iss, aud) ne correspondent pas à la configuration serveur ; la dérive d'horloge entre l'émetteur et le vérificateur dépasse la tolérance autorisée (typiquement ±60 s) ; une modification manuelle a cassé l'encodage Base64URL (n'ajoutez pas de sauts de ligne).
Mon secret ou ma clé privée est-il envoyé à un serveur ?
Non. La signature se fait entièrement dans le navigateur via Web Crypto. Cela dit, ne collez jamais une clé de signature de production dans un outil web — testez avec une clé hors production, puis signez dans votre véritable backend.
Faut-il utiliser HS256 ou RS256 ?
HS256 exige que les deux côtés partagent un secret, donc il convient seulement aux situations où le même service émet et vérifie le jeton. RS256 (ou ES256) permet à l'émetteur de garder une clé privée pendant que chaque consommateur vérifie avec la clé publique — le bon choix pour OAuth/OIDC et toute architecture multi-services. Cet outil ne génère que des tokens de la famille HS ; pour RS256/ES256, utilise un service de signature backend ou un SDK dédié.