Outil d'Analyse JWT
Décoder et vérifier les JSON Web Token, voir l'en-tête, le payload et la signature
JWT exemple
Qu'est-ce que JWT ?
JWT (JSON Web Token) est une norme ouverte (RFC 7519) pour transmettre de manière sécurisée des informations entre des parties. JWT se compose de trois parties séparées par des points : Header contient le type de token et l'algorithme de signature, Payload contient les données de claims, et Signature est utilisée pour vérifier l'intégrité du token. JWT est couramment utilisé pour l'authentification et l'échange d'informations. Avec les JWT, il faut distinguer décodage et vérification. Le header et le payload sont seulement encodés en Base64URL; ils peuvent donc être lus même si la signature est invalide. La confiance vient de la validation côté serveur: signature, algorithme, expiration, émetteur et audience. Les données sensibles ne doivent pas être placées dans un payload non chiffré, car toute personne détenant le token peut les lire. Déboguer un token est utile, mais ce n’est pas l’accepter.
Comment utiliser
Comment utiliser
- Collez un JWT dans la zone de saisie : l'outil analysera et affichera automatiquement le contenu de l'en-tête et du payload
- Cliquez sur les balises colorées pour copier la partie encodée en Base64 correspondante
- Saisissez le secret dans la zone de vérification de signature pour vérifier si la signature est correcte (prise en charge des algorithmes HS256/HS384/HS512)
- La zone d'informations clés affiche les valeurs décodées des claims courants, et l'état d'expiration est codé par couleur
Conseils de sécurité
- Cet outil s'exécute localement dans votre navigateur : le Token n'est jamais envoyé à un serveur
- Le JWT encode et signe uniquement les données, il n'est pas chiffré ; n'importe qui peut le décoder et en lire le contenu
- Ne stockez pas d'informations sensibles dans un JWT (mots de passe, numéros de carte bancaire, etc.)
- Utilisez toujours HTTPS pour transmettre les JWT en environnement de production
Cas d’utilisation
Principe technique
JWT (JSON Web Token, RFC 7519) est composé de trois parties — Header.Payload.Signature — jointes par le point anglais '.'. Header : décrit le type de token et l'algorithme de signature, par ex. {"alg":"HS256","typ":"JWT"}. alg détermine comment la Signature est calculée ; les plus courants sont HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256) et none (aucune signature — interdit en production). Payload : aussi appelé claims, un ensemble de champs JSON. RFC 7519 définit 7 claims enregistrés standards : iss (émetteur), sub (sujet, généralement un identifiant utilisateur), aud (audience), exp (expiration), nbf (pas avant), iat (émis à) et jti (identifiant unique). Les développeurs peuvent ajouter des champs privés supplémentaires, comme userId, role, tenant. Signature : encoder le Header et le Payload en Base64URL, les joindre par un point, puis signer avec l'algorithme spécifié par alg en utilisant une clé. HS256 utilise HMAC-SHA256(secret, header_b64 + '.' + payload_b64) ; RS256 utilise une clé privée RSA. Le destinataire recalcule la signature de la même manière et vérifie si les deux correspondent. Base64URL vs Base64 standard : '+' devient '-', '/' devient '_', et le remplissage '=' final est supprimé, de sorte que le résultat peut être placé dans des chemins URL et des chaînes de requête sans déclencher l'encodage pourcent. Notez que Base64URL est simplement un encodage — il ne fournit ni chiffrement ni sécurité, et n'importe qui peut décoder et lire le payload. Frontière de sécurité : JWT ne garantit que l'« absence de falsification », pas la « confidentialité du contenu ». Une erreur courante consiste à placer des numéros de téléphone, des numéros d'identification ou des hachages de mots de passe dans le payload, où tout le monde peut les voir.
- Structure en trois parties : Header.Payload.Signature, chacune encodée en Base64URL ; la signature est HMAC(secret, header_b64 + '.' + payload_b64) ou RSA(privateKey, même entrée).
- Base64URL remplace '+' par '-', '/' par '_', et supprime le remplissage '=' final, de sorte que le résultat encodé peut être placé directement dans une URL (aucun encodage pourcent déclenché).
- Cet outil ne vérifie localement que les signatures de la famille HMAC (HS256/HS384/HS512). Les algorithmes asymétriques tels que RS256 ou ES256 exigent la clé publique fournie par l'endpoint JWKS de l'émetteur ; la vérification de signature doit donc se faire sur un serveur disposant de cette clé publique — la page peut toujours décoder le header et le payload, mais pas les vérifier.
- Claims standards : iss (émetteur), sub (sujet), aud (audience), exp (expiration, timestamp Unix en secondes), nbf (pas avant), iat (émis à), jti (JWT ID, empêche la relecture).
- Attaque alg=none : le champ alg doit être strictement validé et l'algorithme none doit être rejeté, sinon un attaquant peut falsifier n'importe quel token ; les attaques de substitution d'algorithme (vérifier un token HS256 en utilisant la clé publique comme secret) doivent également être prévenues.
- JWT n'est pas chiffré : le payload est en clair encodé en Base64URL, pas chiffré ; pour du contenu confidentiel, utilisez JWE (JSON Web Encryption), mais en pratique le schéma courant consiste à conserver les données sensibles côté serveur et à y faire référence via le champ sub.
Exemples
Token HS256 standard
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: la RFC 7519 section 3 définit les Registered Claim Names (sub, iat, exp)Token expiré
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Statut: expiré (exp < maintenant)
Note: le claim exp utilise NumericDate (secondes depuis l'epoch Unix selon la RFC 7519 section 2)Token d'informations utilisateur avec claims personnalisés
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
Note: role et tenant sont des claims privés - non définis dans la RFC 7519Checklist de sécurité pour l'implémentation JWT
1. Ne jamais stocker de secrets dans le payload - un JWT est encodé, pas chiffré
2. Utiliser des secrets robustes pour HS256 (>= 256 bits / 32 caractères aléatoires)
3. Préférer RS256/ES256 pour la vérification par clé publique dans les systèmes multi-services
4. Valider l'en-tête alg - rejeter 'none' ou les algorithmes inattendus
5. Vérifier les timestamps exp, nbf, iat avant de faire confiance au token
6. Vérifier que aud correspond à votre service pour empêcher la réutilisation du token entre applications
7. Stocker dans des cookies HttpOnly, pas dans localStorage (protection contre XSS)
RFC: la RFC 8725 (JWT Best Practices) couvre ces considérations de sécuritéFAQ
Quelles sont les trois parties d'un JWT ?
En-tête, charge utile et signature, séparés par des points. L'en-tête déclare l'algorithme de signature et le type de jeton. La charge utile transporte des claims comme sub, iss, aud, iat, exp et toute donnée personnalisée. La signature permet au vérificateur de confirmer que le jeton n'a pas été altéré. L'en-tête et la charge utile sont du JSON encodé en Base64URL — ils sont signés, pas chiffrés.
Un JWT est-il chiffré ?
Non — un JWT au format JWS classique est signé mais non chiffré. Quiconque l'intercepte peut décoder l'en-tête et la charge utile en Base64URL et lire chaque claim, y compris les identifiants utilisateur, les e-mails et les rôles. Considérez le contenu d'un JWT comme une information publique ; n'y placez jamais de mots de passe ni de secrets. Le JWE (JWT chiffré) existe mais reste bien moins répandu.
Que signifie chaque claim standard ?
iss = émetteur ; sub = sujet (souvent l'ID utilisateur) ; aud = audience (destinataire visé) ; exp = expiration (en secondes Unix) ; nbf = pas avant ; iat = émis à ; jti = identifiant unique du jeton pour la révocation. Ils sont définis par la RFC 7519. Des claims personnalisés peuvent être ajoutés librement — préfixez ceux spécifiques à un fournisseur pour éviter les collisions.
Comment vérifier un JWT ?
Lisez l'en-tête alg, utilisez la clé correspondante (HS256 = secret partagé, RS256/ES256 = clé publique du point de terminaison JWKS de l'émetteur), recalculez la signature sur header.payload encodés et comparez. Vérifiez ensuite exp, nbf, iss et aud. Rejetez le jeton si alg vaut « none » ou diffère de ce qu'attend votre serveur. Cet outil ne vérifie localement que les signatures HS256/HS384/HS512 (secret partagé) ; la vérification de RS256/ES256 doit s'exécuter sur un serveur disposant de la clé publique.
La vérification se fait-elle dans mon navigateur ?
Oui. La page parse le JWT localement et vérifie les signatures HS256/HS384/HS512 via HMAC exécuté en JavaScript dans ton navigateur. Le token n'atteint jamais notre serveur, mais souviens-toi qu'un JWT est conçu pour voyager dans les URL et les en-têtes — pars du principe que tout JWT que tu copies peut apparaître dans des logs.
Pourquoi alg=none est-il dangereux ?
La RFC 7519 autorise alg=none pour les jetons non signés. Un vérificateur vulnérable peut accepter un tel jeton bien qu'il n'ait aucune signature, permettant à un attaquant de forger n'importe quelle charge utile. Les bibliothèques modernes rejettent alg=none par défaut ; si vous écrivez un vérificateur vous-même, codez en dur l'algorithme attendu plutôt que de faire confiance à l'en-tête.
Quelle taille un JWT peut-il atteindre ?
Il n'y a pas de limite protocolaire, mais les JWT finissent typiquement dans les en-têtes HTTP (Authorization: Bearer ...) et de nombreux serveurs plafonnent les en-têtes autour de 8 Ko. Bourrer un JWT de claims alourdit chaque requête. Si vous avez besoin de beaucoup d'état de session, utilisez une session côté serveur et placez plutôt un petit jeton de référence dans le JWT.