Génération de JWT en ligne, gratuite

Ce qu'un JWT est vraiment

Un JSON Web Token (JWT), prononcé « djot », est une représentation compacte et URL-safe de revendications à transférer entre deux parties. Le format est composé de trois segments encodés en Base64url séparés par des points : en-tête.payload.signature. L'en-tête déclare le type de jeton (toujours JWT) et l'algorithme de signature (souvent HS256, RS256 ou ES256). Le payload porte les revendications, un objet JSON avec des champs standards comme iss (émetteur), sub (sujet), aud (audience), exp (heure d'expiration en timestamp Unix), nbf (pas avant), iat (émis à), jti (identifiant du JWT), plus toute revendication propre à l'application que l'émetteur souhaite inclure. La signature est la preuve cryptographique que l'en-tête et le payload n'ont pas été altérés, produite en signant la chaîne concaténée base64url(en-tête).base64url(payload) avec l'algorithme et la clé déclarés dans l'en-tête. JWT a été spécifié par Michael B. Jones, John Bradley et Nat Sakimura dans la RFC 7519 en mai 2015, sur la base des travaux antérieurs de JOSE (JSON Object Signing and Encryption, RFC 7515 à 7520). Le format est devenu la forme de jeton dominante dans l'authentification web moderne, utilisé par les implémentations OAuth 2.0 / OIDC, les passerelles d'API, les jetons de session des SPA, l'authentification microservice-à-microservice, et la gestion de session par cookie à grande échelle.

Le choix de l'algorithme de signature, HS256 vs RS256 vs ES256

JWT prend en charge plusieurs algorithmes de signature enregistrés dans le registre des algorithmes JOSE (RFC 7518). HS256 (HMAC-SHA256) est le plus simple : un algorithme symétrique où le même secret sert à signer et à vérifier. Peu coûteux à calculer, facile à implémenter, et adapté quand le signataire et le vérificateur sont la même partie (par exemple, une application qui s'émet à elle-même des jetons de session). RS256 (RSA-SHA256) est asymétrique : la clé privée signe, la clé publique vérifie. Utilisé quand l'émetteur et le vérificateur sont des parties différentes, Auth0, Okta, Google Identity Platform, Microsoft Entra ID et la plupart des fournisseurs d'identité cloud émettent des JWT signés en RS256, parce que les clients peuvent vérifier la signature via un endpoint JWKS (JSON Web Key Set) publié sans avoir à partager de secret. ES256 (ECDSA P-256 SHA-256) est l'équivalent en courbe elliptique de RS256, même modèle clé publique/clé privée, clés bien plus courtes (256 bits contre le minimum de 2048 de RSA), vérification plus rapide. EdDSA (Ed25519) est le successeur moderne d'ES256, légèrement plus rapide et aux propriétés cryptographiques plus propres ; pris en charge dans les bibliothèques JWT récentes mais pas encore universel. none est un mode « sans signature » autorisé par la spécification JWT qui a provoqué des incidents de sécurité dans plusieurs bibliothèques quand les implémentations n'ont pas su rejeter les jetons alg: none: la leçon : les vérificateurs JWT doivent explicitement vérifier que l'algorithme correspond à celui attendu. Ce générateur utilise HS256 parce qu'il ne demande qu'un secret partagé plutôt qu'une génération de clés ; pour un usage en production des algorithmes asymétriques, une bibliothèque côté serveur est le bon outil.

Quand vous avez besoin de générer un JWT à la main

• Tester des points de terminaison d'API. Une API exige un JWT dans l'en-tête Authorization, pour la tester à la main avec curl, Postman ou HTTPie, il vous faut un jeton. Générez un JWT de test à la bonne forme, signez-le avec le secret partagé de l'API (en environnements de dev), et utilisez le résultat.
• Reproduire un bug lié à un jeton. Un utilisateur signale un problème d'authentification. Reconstruisez le jeton qu'il aurait dû recevoir avec ses revendications, examinez la signature, vérifiez la logique de vérification de votre service contre un jeton connu-bon et un jeton connu-mauvais.
• Développement local sans fournisseur d'auth. Vous construisez un frontend face à une API qui attend une authentification JWT, mais vous n'avez pas encore accès au fournisseur d'identité de production. Générez des JWT de test avec des revendications réalistes pour le développement.
• Apprendre le format JWT. Décoder un JWT, changer une revendication, le re-signer, voir ce que fait votre application. La boucle de débogage-par-bricolage est la façon dont la plupart des développeurs finissent par comprendre la structure JWT.
• Jetons internes service-à-service. Deux microservices internes partagent un secret et utilisent JWT pour authentifier les requêtes. Le modèle HS256 à secret partagé convient ici ; cet outil peut générer les jetons à la main à des fins de test.

Pièges de sécurité, où les JWT déraillent

Les JWT ont une longue histoire d'erreurs d'implémentation qui ont produit de vrais incidents de sécurité. L'attaque « alg: none » : les premières bibliothèques JWT acceptaient les jetons avec le champ algorithme à « none » (pas de signature), permettant à un attaquant de forger n'importe quel jeton. Les vérificateurs doivent imposer explicitement l'algorithme attendu. Confusion d'algorithme : un vérificateur qui accepte à la fois RS256 et HS256 peut être berné en utilisant la clé RSA publique comme secret HMAC, l'attaquant signe en HS256 avec la clé publique, le vérificateur (mal-)vérifie en HMAC avec cette même clé publique. Les vérificateurs doivent fixer l'algorithme attendu. Données sensibles dans le payload : les revendications JWT sont encodées en Base64 mais non chiffrées. Quiconque détient le jeton peut lire chaque revendication. Ne mettez jamais de mots de passe, de numéros de carte de crédit complets ou d'autres secrets dans le payload. Pas d'expiration : les JWT sans revendication exp sont valides à jamais. Définissez toujours une expiration raisonnable (quelques minutes pour les jetons d'accès, quelques jours pour les jetons de rafraîchissement). Pas de révocation : les JWT sont autonomes, une fois émis, ils restent valides jusqu'à exp, peu importe que l'utilisateur se déconnecte, change de mot de passe ou que son compte soit suspendu. Acceptez cette limite, maintenez une liste de révocation (ce qui réduit en partie l'intérêt du jeton sans état), ou utilisez des jetons d'accès courts avec rotation des jetons de rafraîchissement. Stockage en localStorage vs cookies : un JWT en localStorage est accessible à n'importe quel JavaScript de la page (risque XSS) ; un JWT en cookie HttpOnly ne l'est pas (mais est envoyé automatiquement avec les requêtes inter-origines, risque CSRF). Les deux ont leurs compromis ; la bonne pratique moderne penche vers les cookies HttpOnly avec restrictions SameSite plus jetons CSRF.

JWT vs cookies de session vs PASETO

JWT n'est pas le seul choix. Les cookies de session traditionnels stockent un identifiant de session opaque ; le serveur conserve l'état réel de la session dans une base de données ou un cache. Avantages : révocation triviale (supprimer l'enregistrement côté serveur), aucun risque de fuite de données de revendications, aucune complexité de signature. Inconvénients : nécessite une consultation du store de session à chaque requête (latence), plus difficile à mettre à l'échelle entre services. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) est un remplaçant de JWT conçu pour éviter les pièges de confusion d'algorithme et de « none », format versionné, pas de négociation d'algorithme, signatures obligatoires, choix de chiffrements restreints. PASETO a pris pied dans des contextes sensibles à la sécurité mais n'a pas supplanté JWT dans l'écosystème plus large. Macaroons (Google, 2014) sont un format de jeton plus flexible, avec restrictions de capacités enchaînables, mais ils sont essentiellement resté un objet de recherche en 2026. OAuth 2.1 consolide les bonnes pratiques d'OAuth 2.0, JWT reste le format type de jeton d'accès. Le choix pragmatique en 2026 reste JWT pour les microservices sans état et les jetons d'API, les cookies de session opaques pour les applications web rendues côté serveur traditionnelles, et PASETO comme alternative moderne pour les nouveaux projets greenfield qui veulent des défauts plus solides.

Questions fréquentes

Puis-je décoder un JWT sans la clé secrète ?

Oui. Les JWT sont signés mais pas chiffrés : l'en-tête et la charge utile restent donc lisibles. La clé secrète n'est nécessaire que pour vérifier la signature ou générer un nouveau jeton.

Est-il sûr de coller ici des JWT de production ?

Oui. Tout le traitement s'effectue localement dans votre navigateur. Vos jetons et vos clés secrètes ne sont jamais envoyés à un serveur ni stockés où que ce soit.

Quelle est la différence entre HS256, RS256 et ES256 ?

HS256 utilise une clé secrète partagée (HMAC-SHA256). RS256 utilise des paires de clés RSA ; ES256 utilise la cryptographie à courbes elliptiques. Cet outil prend en charge HS256, le plus courant pour les API web.