JWT (JSON Web Token) est une norme ouverte définie par l'IETF dans la RFC 7519 (la RFC 7515 décrit la forme de signature JWS, la RFC 7516 décrit le chiffrement JWE, la RFC 7517 définit les clés JWK) pour transférer en toute sécurité des informations utilisateur 'affirmées' entre les requêtes HTTP, les flux OIDC et les appels de microservices. Une chaîne JWT standard se compose de trois segments encodés en Base64URL : Header (algorithme et type), Payload (Claims, les données utilisateur) et Signature (une signature basée sur une clé sur les deux premiers). Les trois segments sont joints par un point littéral `.`, par exemple `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT n'est pas du chiffrement.** C'est l'idée fausse la plus courante. Le Payload est en texte clair par défaut — n'importe qui peut le décoder avec Base64URL et lire le contenu. JWT fournit une **détection de falsification**, pas de la confidentialité : le serveur resigne Header.Payload avec la clé partagée et la compare à la Signature du token. Si elles correspondent, le token n'a pas été modifié en transit. C'est la métaphore du 'billet de train avec un tampon anti-contrefaçon' : l'inspecteur se soucie de savoir si le billet est authentique, pas si le code QR est illisible.
JWT divise clairement les responsabilités entre 13 algorithmes. **Famille HMAC** (HS256/HS384/HS512) utilise une clé symétrique à la fois pour signer et vérifier, rapide et simple, adaptée à un seul service ou à un cluster de confiance ; le secret doit avoir au moins la longueur du digest (par exemple, ≥ 32 octets pour HS256). **Famille RSA** (RS256/RS384/RS512) utilise RSASSA-PKCS1-v1_5, le schéma asymétrique le plus courant — les signataires détiennent la clé privée, les vérificateurs détiennent la clé publique. **Famille RSA-PSS** (PS256/PS384/PS512) utilise le remplissage RSA-PSS plus récent avec des garanties de sécurité plus fortes, préféré par AWS SigV4 et les fournisseurs d'identité OIDC modernes. **Famille ECDSA** (ES256/ES384/ES512) utilise des courbes elliptiques (P-256/P-384/P-521 respectivement) avec des signatures plus courtes et de meilleures performances. **EdDSA** (principalement Ed25519) est extrêmement rapide et déterministe (même message + même clé = même signature à chaque fois) et est l'algorithme recommandé dans OAuth 2.1 et les nouveaux protocoles.
La sécurité est là où JWT trébuche en production. La OWASP JWT Cheat Sheet souligne au moins quatre règles strictes : (1) ne jamais mettre de mots de passe, de pièces d'identité, de numéros de carte ou de clés API en texte clair dans le Payload ; (2) le serveur **ne doit jamais faire confiance au champ alg** déclaré dans le Header du Token — il doit vérifier avec un algorithme codé en dur, sinon un attaquant qui réécrit l'en-tête à `alg: none` contourne tout (c'est la racine des CVE historiques comme CVE-2015-9235) ; (3) les secrets HMAC doivent être aléatoires et avoir au moins 32 octets, jamais des chaînes courtes ; (4) la vérification est plus que la vérification de signatures — vous devez également valider `exp` (expiration), `nbf` (pas avant), `iss` (émetteur) et `aud` (audience). Cet outil met en évidence chacun de ces Claims dans l'interface utilisateur pour que vous puissiez dire d'un coup d'œil si un échec est un problème de signature, un problème de timing ou un problème de Claims.
JWT n'est pas un remplacement pour les sessions. Les sessions stockent l'état de l'utilisateur sur le serveur (Redis ou une base de données) ; JWT emballe l'état dans le token. Les architectures de microservices, les API sans état, les clients mobiles et les configurations avec beaucoup de CORS bénéficient de JWT ; les systèmes d'entreprise traditionnels et les flux qui nécessitent une révocation instantanée (par exemple, 'expulser cet utilisateur maintenant') sont encore mieux servis par les sessions. Cet outil couvre à la fois le débogage JWT pur et les étapes d'analyse de Token / vérification de signature / modification de Payload d'une migration de session vers JWT.