Décoder
Vérifier
Créer
Tester authz
Guide d'utilisation
Qu'est-ce qu'un JWT
Un JWT (JSON Web Token) est une créance compacte et signée qui voyage sous forme de chaîne de texte. Il est surtout utilisé comme token d'accès dans les API, les logins et OAuth 2.0 / OpenID Connect : le client l'envoie à chaque requête dans l'en-tête Authorization: Bearer … et le serveur vérifie la signature pour savoir qui vous êtes et ce que vous pouvez faire sans consulter de base de données. La signature garantit que personne ne l'a manipulé, mais elle ne chiffre pas son contenu : n'importe qui peut le lire (cet outil le fait lui-même).
Les trois parties
Un JWT a trois parties séparées par des points : header.payload.signature.
• Header (en-tête) — JSON avec l'algorithme de signature (alg) et le type (typ: JWT) ; parfois un kid qui identifie la clé utilisée.
• Payload (charge utile) — JSON avec les claims : les données du token (utilisateur, permissions, expiration…).
• Signature — le résultat de la signature de header.payload avec l'algorithme du header.
Le header et le payload sont encodés en Base64URL (ce n'est pas du chiffrement, juste du texte sûr pour les URL). Cet outil les décode en JSON lisible et colore les trois parties.
Comment l'utiliser
Deux façons de travailler :
• Décoder — colle un token dans l'onglet Décoder et tu verras instantanément le header, le payload et un tableau des claims avec leur signification et leur expiration. Pas besoin de la clé pour le lire.
• Créer — dans l'onglet Créer tu écris le payload (JSON), choisis l'algorithme, fournis le secret ou la clé privée et obtiens un token signé.
Le token qui vient d'être créé, tu l'envoies en un clic vers Vérifier ou vers le visualiseur de flux d'authentification. Tout se passe dans ton navigateur : ni les tokens ni les clés ne quittent ta machine.
Algorithmes de signature (un par un)
Le champ alg du header indique avec quel algorithme il a été signé. Cet outil en prend en charge 12, en trois familles ; le nombre est la taille du hash SHA (256/384/512).
• HS256 / HS384 / HS512 (HMAC + SHA) — symétriques : la même clé secrète signe et vérifie. Simples et rapides. Utilisez-les quand celui qui signe et celui qui vérifie sont la même partie ou partagent le secret de manière sécurisée (p. ex. un backend qui émet et consomme ses propres tokens). Inconvénient : quiconque peut vérifier peut aussi falsifier.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — asymétriques : signé avec la clé privée et vérifié avec la clé publique. Les plus répandus en OAuth/OIDC : l'émetteur garde la privée et publie la publique (JWKS) pour que quiconque puisse vérifier sans pouvoir falsifier. Clés volumineuses (2048 bits) et signature plus lente.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — RSA asymétrique comme RS, mais avec un remplissage PSS (probabiliste), considéré plus robuste. À choisir si votre plateforme le prend en charge et que vous voulez le RSA moderne.
• ES256 / ES384 / ES512 (ECDSA + courbes P-256/P-384/P-521) — asymétriques à courbe elliptique : mêmes garanties que RSA mais avec des clés et signatures bien plus petites et rapides. Bon choix par défaut pour les nouveaux tokens.
Règle pratique : HS* si vous partagez un secret dans un environnement contrôlé ; ES* ou RS*/PS* si des tiers doivent vérifier sans pouvoir émettre.
Vérifier la signature
Dans Vérifier, la signature est contrôlée pour de vrai (cryptographie Web Crypto du navigateur) :
• Choisis l'algorithme (celui déclaré dans le header est présélectionné).
• S'il s'agit de HS*, colle le secret. S'il s'agit de RS/PS/ES*, colle la clé publique en PEM (-----BEGIN PUBLIC KEY-----) ou en JWK (JSON) ; l'outil détecte de laquelle il s'agit.
• Tu verras Signature valide ou invalide, plus les contrôles d'expiration (exp) et de « pas encore valide » (nbf).
Deux protections clés : alg:none (tokens non signés) est toujours rejeté, et tu es averti de la confusion d'algorithme — vérifier comme HMAC un token asymétrique (ou l'inverse) est une faille de sécurité connue. La clé ne quitte jamais ta machine.
Créer et signer
Dans Créer, tu construis et signes un token :
• Écris le payload en JSON ; avec les puces tu ajoutes rapidement des claims standards (sub, iss, aud, exp…) ou courants (name, role, scope…) avec des valeurs d'exemple.
• Choisis l'algorithme et fournis le secret (HS*) ou la clé privée PEM/JWK (RS/PS/ES*). Optionnel : un kid dans le header.
• Générer des clés crée instantanément un secret aléatoire (HMAC) ou une paire de clés (privée + publique en PEM et JWK) pour tester.
• Signe et copie le token. En un clic, envoie-le vers Vérifier (aller-retour) ou vers le flux d'authentification.
Claims standard et expiration
Les claims sont les champs du payload. Les enregistrés (RFC 7519) ont une signification standard :
• iss — émetteur : qui a créé le token.
• sub — sujet : qui il identifie (généralement l'utilisateur).
• aud — audience : pour qui il est destiné ; le destinataire doit en faire partie.
• exp — expiration : instant après lequel il n'est plus valide.
• nbf — pas avant : n'est pas valide avant cet instant.
• iat — émis le : quand il a été créé.
• jti — ID unique : utile pour la révocation ou l'anti-rejeu.
Les temps sont en secondes Unix (secondes depuis 1970). L'outil les affiche en date locale et en relatif (« il y a 3 h », « dans 42 min ») et marque en rouge si le token est expiré (exp dépassé) ou pas encore valide (nbf futur). Attention : décoder ne valide pas — l'expiration ne s'impose que si le serveur la vérifie lors de la validation.
Tester l'authz
L'onglet Tester l'authz simule la décision d'une passerelle ou d'une API : vous définissez les règles que vous exigeriez (émetteur, audience, scopes/rôles) et l'outil confronte le token collé et affiche ALLOW ou DENY règle par règle, en indiquant ce qui manque ou ne correspond pas (y compris exp et nbf). Cela permet de comprendre pourquoi un token serait accepté ou rejeté sans monter le backend.
Sécurité
Points clés :
• La signature prouve l'intégrité et l'origine, mais ne chiffre pas : le payload est lisible par n'importe qui. Ne mets jamais de données sensibles (mots de passe, cartes…) dans un JWT sans chiffrement supplémentaire (JWE).
• Traite les tokens comme des secrets : ne les colle pas dans des endroits publics et ne les stocke pas dans des dépôts. Les exemples ici utilisent des secrets et clés jouets ; pour la production, utilise de vraies clés générées de façon sûre et ne les colle pas dans cet outil.
• Mets toujours exp (expiration courte) et vérifie sur le serveur la signature et l'algorithme attendu. Rejette alg:none et la confusion d'algorithme.
• Tout le travail se fait localement dans ton navigateur : rien n'est envoyé à un serveur.
