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).

Un JWT se compose de trois parties séparées par des points : header.payload.signature. Le header et le payload sont encodés en Base64URL ; cet outil les décode en JSON lisible.

Collez un token JWT (trois parties séparées par des points) pour voir le header, le payload décodé et les métadonnées (expiration, iat, etc.).

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.

Dans l'onglet Vérifier, vous contrôlez réellement la signature (HS/RS/ES/PS) en fournissant le secret (HMAC) ou la clé publique (PEM ou JWK). alg:none est rejeté et la confusion d'algorithme est signalée. Tout se passe dans votre navigateur : la clé ne quitte jamais votre appareil.

Dans Créer vous construisez un JWT à partir de champs et le signez (secret HMAC ou paire de clés que vous pouvez générer). Dans Tester authz vous définissez les règles d'une gateway (issuer, audience, scopes/rôles) et voyez si le token donnerait ALLOW ou DENY.

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.

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.

La signature garantit que le token n'a pas été altéré, mais elle ne chiffre pas le contenu : n'importe qui peut lire le payload. N'incluez jamais de données sensibles sans chiffrement supplémentaire (JWE).