Générateur JWT

Bienvenue sur le Générateur JWT, un outil en ligne rapide et gratuit pour créer des JSON Web Tokens signés. Que vous testiez un flux d'authentification, construisiez une API, débugguiez une intégration ou appreniez comment les JWT fonctionnent sous le capot, ce générateur vous donne un contrôle total sur l'en-tête du jeton, les revendications de la charge utile (payload) et l'algorithme de signature HMAC. Sortez un jeton HS256, HS384 ou HS512 valide en un clic et inspectez chaque segment côte à côte.

Qu'est-ce qu'un JSON Web Token ?

Un JSON Web Token (JWT) est un format d'identification compact et sûr pour les URL défini par la RFC 7519. Un JWT transporte des revendications sur un sujet entre deux parties et prouve son intégrité par une signature cryptographique. Comme le jeton est autonome, le destinataire peut le valider sans avoir à rappeler l'émetteur — une propriété qui fait des JWT la pierre angulaire de l'authentification sans état pour les applications web et mobiles modernes.

Chaque JWT est construit à partir de trois parties encodées en base64url jointes par des points :

• En-tête (Header) — un objet JSON qui déclare le type de jeton (typ) et l'algorithme de signature (alg).
• Charge utile (Payload) — un objet JSON qui contient les revendications, telles que l'ID de l'utilisateur, l'heure d'expiration et toute donnée personnalisée.
• Signature — une signature HMAC ou RSA sur l'en-tête et la charge utile encodés qui les protège contre les altérations.

Comment fonctionne le Générateur JWT

Cet outil suit la recette exacte de signature JWT de la RFC 7519 §7.1 :

1. Sérialiser le JSON de l'en-tête vers sa forme compacte (sans espaces) et l'encoder en base64url.
2. Faire de même pour le JSON de la charge utile.
3. Concaténer les deux avec un séparateur point. C'est l'entrée de signature.
4. Calculer le HMAC de l'entrée de signature en utilisant votre secret et l'algorithme SHA-2 choisi.
5. Encoder en base64url les octets de signature résultants.
6. Concaténer le tout sous la forme en-tête.charge_utile.signature.

Ce qui rend ce générateur différent

• Visualisation couleur en trois segments — en-tête (rose), charge utile (violet), signature (cyan) pour que vous puissiez repérer chaque partie instantanément.
• Palette de Revendications Rapides — insertion en un clic de iss, sub, aud, iat, nbf et jti.
• Aide à l'expiration — boutons prédéfinis pour 1 heure, 1 jour, 7 jours ou 30 jours qui calculent automatiquement le bon horodatage Unix.
• Aperçu du jeton en direct — l'en-tête et la charge utile encodés se mettent à jour au fur et à mesure que vous tapez pour que vous puissiez voir comment chaque modification change le jeton.
• Synchronisation intelligente de l'en-tête — le changement d'algorithme met à jour automatiquement le champ alg de l'en-tête.
• Bascule de secret Base64 — si votre secret est stocké en base64 (la convention JWS pour les clés binaires), activez l'option et l'outil le décode avant la signature.
• Boutons de copie par segment — copiez l'en-tête, la charge utile, la signature ou le jeton complet indépendamment.
• Résumé des revendications — les revendications standard reconnues sont listées avec une description et un horodatage lisible par l'homme le cas échéant.

Choisir le bon algorithme

Les trois variantes HMAC prises en charge par cet outil sont fonctionnellement identiques, à l'exception du hachage SHA-2 sous-jacent et de la longueur de la signature :

• HS256 — HMAC avec SHA-256. Signature de 256 bits. Le standard pour presque toutes les bibliothèques d'émission de JWT et le choix le plus interopérable.
• HS384 — HMAC avec SHA-384. Signature de 384 bits. Marge légèrement plus grande contre la cryptanalyse future.
• HS512 — HMAC avec SHA-512. Signature de 512 bits. Utile lorsque la politique exige le hachage standard le plus long.

Tous trois reposent sur un secret partagé que l'émetteur et le vérificateur détiennent. La RFC 7518 §3.2 exige que la clé soit au moins aussi longue que la sortie de hachage : 256 bits pour HS256, 384 bits for HS384, 512 bits for HS512.

Revendications (Claims) Enregistrées Standard

La RFC 7519 §4.1 définit un petit ensemble de revendications standard que les émetteurs et vérificateurs de JWT devraient reconnaître. Elles sont toutes facultatives mais largement prises en charge :

• iss (émetteur) — identifie qui a créé le jeton. Souvent une URL ou un nom de service.
• sub (sujet) — identifie de qui parle le jeton, généralement un ID utilisateur.
• aud (audience) — identifie le destinataire auquel le jeton est destiné. Peut être une chaîne unique ou un tableau.
• exp (temps d'expiration) — horodatage Unix après lequel le jeton doit être rejeté.
• nbf (pas avant) — horodatage Unix avant lequel le jeton ne doit pas être accepté.
• iat (émis à) — horodatage Unix enregistrant le moment où le jeton a été créé.
• jti (ID JWT) — un identifiant unique qui permet de révoquer ou de suivre les jetons individuellement.

Comment utiliser cet outil

1. Choisir un algorithme de signature — cliquez sur HS256, HS384 ou HS512. L'en-tête est mis à jour automatiquement pour correspondre.
2. Modifier l'en-tête (facultatif) — l'en-tête par défaut contient alg et typ. Ajoutez un kid (ID de clé) personnalisé si votre vérificateur en a besoin.
3. Construire la charge utile — tapez vos revendications en JSON ou cliquez sur les boutons de Revendications Rapides pour insérer des champs standard. L'aide à l'expiration écrit un horodatage Unix correct pour la durée relative que vous choisissez.
4. Définir le secret — entrez votre secret partagé HMAC. Basculez l'icône de l'œil pour le révéler. Si votre secret est encodé en base64, cochez la case pour que l'outil le décode avant la signature.
5. Générer le JWT — cliquez sur Générer le JWT. Le jeton complet, les trois cartes de segments, le schéma de structure et le résumé des revendications reconnues sont affichés ensemble.
6. Copier ce dont vous avez besoin — utilisez les boutons Copier par segment ou le bouton Copier le Jeton pour emmener la valeur encodée dans Postman, curl ou votre application client.

Cas d'utilisation courants

Authentification et Autorisation

• Émettre des jetons d'accès après une connexion réussie.
• Encoder l'identité de l'utilisateur (sub) plus les revendications de rôle ou de permission.
• Signer des jetons à courte durée de vie (15–60 minutes) et les rafraîchir au besoin.

Tests d'intégration d'API

• Construire des jetons factices pour tester comment votre API répond à des revendications expirées, antidatées ou malformées.
• Générer des JWT fixes pour les tests unitaires et les pipelines CI.
• Reproduire des jetons de type production dans un environnement local sans solliciter le véritable serveur d'authentification.

Débogage de l'authentification unique (SSO)

• Comparer un JWT connu comme bon à celui que votre fournisseur envoie pour trouver des écarts de spécification.
• Vérifier l'algorithme de signature et l'ID de clé (kid) utilisé par un émetteur en amont.

Foire Aux Questions

Le JWT créé ici est-il un jeton réel et valide ?

Oui. Le jeton est signé avec HMAC sur l'en-tête et la charge utile encodés canoniques. Toute bibliothèque JWT qui utilise votre même secret le validera avec succès.

Pourquoi mon jeton ressemble-t-il à ce que je génère ailleurs ?

Parce que les JWT sont déterministes : avec le même en-tête, la même charge utile et le même secret, chaque bibliothèque conforme produit exactement la même chaîne. Si vous voyez une différence, vérifiez que l'ordre de sérialisation JSON, l'orthographe des clés et l'encodage du secret correspondent tous.

Puis-je décoder un JWT pour vérifier ce que j'ai généré ?

Oui. Associez cet outil à un décodeur JWT pour inspecter les segments. Le décodage ne fait qu'inverser l'étape base64url — la vérification de la signature nécessite toujours le secret.

Pourquoi mon secret est-il rejeté comme étant trop court ?

La RFC 7518 recommande une clé d'au moins la longueur de sortie du hachage : 256 bits pour HS256. L'outil lui-même n'impose pas de minimum, mais un vérificateur bien élevé peut rejeter les clés courtes. Utilisez un secret de plus de 32 octets généré aléatoirement en utilisation réelle.

Cet outil prend-il en charge RS256, ES256 ou EdDSA ?

Pas encore — cet outil se concentre sur les algorithmes basés sur HMAC car ils ne nécessitent qu'une chaîne partagée. Les algorithmes asymétriques (RS*, PS*, ES*, EdDSA) nécessitent des paires de clés et une manipulation PEM qui sont mieux adaptés à des outils dédiés.

Mon secret et ma charge utile sont-ils envoyés au serveur ?

Le formulaire est soumis via HTTPS pour calculer la signature. Rien n'est enregistré ou stocké au-delà de la durée de vie de la requête. Ne saisissez pas de secrets de production ici quoi qu'il en soit — traitez-le comme un environnement de test public.

Ressources Additionnelles

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7518 - JSON Web Algorithms (JWA)
• JSON Web Token - Wikipédia