Aller au contenu
SPCX Tools

Encodeur JWT

Générez et signez des JSON Web Tokens (JWT) basés sur HMAC instantanément dans votre navigateur.

Fonctionne en local — vos fichiers ne quittent pas votre appareil

Chargement de l’outil…

Comment utiliser : Encodeur JWT

  1. 1Sélectionnez l'algorithme de signature HMAC de votre choix (HS256, HS384 ou HS512).
  2. 2Modifiez le payload JSON. Utilisez les boutons rapides pour insérer l'heure actuelle dans les claims standards tels que iat et exp.
  3. 3Saisissez votre clé secrète. Si votre système utilise un secret encodé en Base64, cochez la case Base64.
  4. 4Le token signé se met à jour automatiquement au fur et à mesure de votre saisie. Cliquez sur Copier pour récupérer le JWT final.

Un encodeur JWT local et sécurisé

Cet encodeur JWT permet aux développeurs de créer, modifier et signer rapidement des JSON Web Tokens directement dans le navigateur. Que vous conceviez un flux d'authentification, testiez un endpoint d'API ou déboguiez un microservice, vous pouvez générer des tokens valides à la volée sans écrire de scripts spécifiques ni exposer vos identifiants à des serveurs tiers.

Comme l'outil s'appuie sur l'API Web Crypto native de votre navigateur, tout le traitement des données et la signature cryptographique s'effectuent entièrement sur votre appareil. Votre payload JSON et vos clés secrètes ne sont jamais envoyés, stockés ou journalisés. Cette approche 100 % locale permet de signer des JWT en ligne en toute sécurité, même avec des identifiants de développement ou de préproduction sensibles.

Comment créer un token JWT

Pour créer un token JWT, trois éléments sont nécessaires : un header (qui définit l'algorithme), un payload (qui contient vos données) et une clé secrète (qui sécurise le token).

Commencez par sélectionner votre algorithme. Cet outil fonctionne comme un puissant générateur de JWT HS256, mais prend également en charge le HS384 et le HS512. Il s'agit d'algorithmes HMAC symétriques, ce qui signifie que la même clé secrète est utilisée pour signer le token et pour le vérifier ultérieurement. Plus le nombre est élevé (par ex. 512), plus la taille du hash généré est grande, ce qui offre une sécurité cryptographique renforcée au prix d'un token légèrement plus long.

Ensuite, définissez votre payload dans la zone de texte. Le payload doit être un JSON valide. À mesure que vous modifiez le JSON ou la clé secrète, l'outil recalcule la signature en temps réel, vous alertant immédiatement en cas d'erreur de syntaxe dans votre structure JSON. Une fois le payload et le secret définis, le token final est prêt à être copié et utilisé dans les en-têtes Authorization ou les cookies de votre application.

Cas d'utilisation courants pour la génération de tokens

Avoir un générateur JWT fiable à portée de main est essentiel pour le développement web moderne. Les développeurs utilisent fréquemment cet outil pour divers scénarios de test et de débogage :

Test des endpoints API : Lorsque vous utilisez des clients API comme Postman ou Insomnia, vous avez souvent besoin d'un bearer token valide pour accéder aux routes protégées. Au lieu de lancer toute votre application frontend pour vous connecter et récupérer un token, vous pouvez en générer un manuellement ici avec l'ID utilisateur et les rôles exacts dont vous avez besoin.

Débogage de la logique d'authentification : Si votre backend rejette les tokens, créer un token manuellement permet d'isoler le problème. Vous pouvez ainsi vérifier si l'erreur provient d'une clé secrète incorrecte, d'un payload malformé ou d'un algorithme de signature inadapté.

Création de cas limites : Il est crucial pour la sécurité de tester la façon dont votre backend gère les tokens expirés, les claims manquants ou les rôles non autorisés. Vous pouvez facilement manipuler le payload JSON ici pour reproduire ces cas particuliers et vous assurer que votre serveur renvoie les bons codes d'état HTTP.

Gestion des timestamps et des claims

Les JSON Web Tokens utilisent des champs spécifiques, appelés claims, pour transmettre des informations sur le cycle de vie du token et l'utilisateur qu'il représente. Les claims temporels les plus courants sont iat (Issued At) et exp (Expiration Time). Ces deux claims nécessitent un timestamp Unix, qui correspond au nombre de secondes écoulées depuis le 1er janvier 1970.

Calculer ces timestamps manuellement peut être fastidieux lors des tests. Pour accélérer votre workflow, cet outil inclut des boutons d'action rapide au-dessus de l'éditeur de payload.

  • Cliquer sur iat = now injecte ou met à jour instantanément le champ iat avec l'heure Unix actuelle.
  • Cliquer sur exp = +1h ou exp = +24h calcule le timestamp futur et met à jour le champ exp en conséquence.

Cela garantit que vos tokens générés sont immédiatement valides et ne seront pas rejetés prématurément par la logique de validation temporelle de votre serveur.

Gestion des secrets Base64

Un problème fréquent lors de la signature d'un JWT en ligne est la gestion de l'encodage de la clé secrète. De nombreux systèmes backend et tutoriels recommandent de générer un tableau d'octets aléatoire et robuste pour votre secret HMAC, puis de le stocker sous forme de chaîne Base64 dans vos variables d'environnement.

Si votre serveur décode cette chaîne Base64 en octets bruts avant de signer ou de vérifier le token, coller la chaîne Base64 directement dans un générateur standard produira une signature invalide. Le générateur traitera les caractères Base64 comme du texte brut, ce qui entraînera une erreur de correspondance.

Pour résoudre ce problème, cochez simplement la case Secret encodé en Base64. L'outil décodera votre chaîne secrète pour retrouver les octets bruts d'origine avant d'appliquer le hachage HMAC, garantissant ainsi que la signature finale corresponde parfaitement à votre environnement backend.

Comprendre la structure d'un JWT

Lorsque vous générez un token, le résultat s'affiche avec un code couleur pour vous aider à comprendre sa structure. Un JWT standard se compose de trois parties séparées par des points (.) :

  1. En-tête (Rouge) : Contient les métadonnées du token, principalement l'algorithme de signature (ex. : {"alg":"HS256","typ":"JWT"}). Il est généré automatiquement en fonction de l'algorithme choisi et encodé en Base64-URL.
  2. Payload (Bleu) : Vos données JSON, également encodées en Base64-URL. Cette partie est facilement lisible par quiconque intercepte le token, c'est pourquoi vous ne devez jamais inclure de mots de passe ou de données très sensibles dans le payload.
  3. Signature (Vert) : Le hash cryptographique de l'en-tête et du payload encodés, signé avec votre clé secrète. Cela garantit que le token n'a pas été altéré lors du transfert.

Si vous avez déjà un token et souhaitez voir son contenu sans la clé secrète, vous pouvez le coller dans notre Décodeur JWT pour inspecter l'en-tête et le payload en toute sécurité.

Questions fréquentes

Quels algorithmes cet outil prend-il en charge ?
Cet outil prend actuellement en charge les algorithmes basés sur HMAC : HS256 (HMAC avec SHA-256), HS384 et HS512. Ce sont des algorithmes symétriques, ce qui signifie que la même clé secrète est utilisée pour signer et vérifier le jeton.
Ma clé secrète est-elle envoyée à un serveur ?
Non. Toute la signature cryptographique est effectuée localement dans votre navigateur à l'aide de l'API Web Crypto. Votre payload JSON et votre clé secrète ne quittent jamais votre appareil, ce qui en fait un moyen sécurisé de générer des jetons de test.
À quoi sert la case à cocher Base64 ?
Dans de nombreux frameworks backend, le secret JWT est stocké sous forme de chaîne encodée en Base64 plutôt qu'en texte brut. Cocher cette case décode votre entrée en octets bruts avant d'appliquer l'algorithme HMAC, ce qui garantit que la signature générée correspond exactement à ce qu'attend votre serveur.
Comment fonctionnent les boutons de temps ?
Les boutons pour iat (date d'émission) et exp (date d'expiration) insèrent des timestamps Unix standards (le nombre de secondes écoulées depuis le 1er janvier 1970) dans votre payload JSON. Cela vous évite de chercher ou de calculer manuellement l'heure Epoch actuelle.
Pourquoi mon jeton est-il invalide lorsque j'essaie de le vérifier sur mon serveur ?
Les causes les plus courantes sont une clé secrète qui ne correspond pas, un algorithme incorrect ou une différence dans l'encodage du secret. Assurez-vous d'utiliser exactement la même chaîne secrète et vérifiez si votre serveur nécessite que le secret soit décodé en Base64 avant la signature.