Analyseur JWT
Décodez et inspectez des JSON Web Tokens (JWT) avec validation en temps réel. Consultez l'en-tête, la charge utile et la signature de manière sécurisée dans votre navigateur.
Définition: Un JSON Web Token est constitué de trois parties encodées en Base64URL — en-tête, charge utile, signature — jointes par des points. L'en-tête nomme l'algorithme de signature, et la signature est vérifiée avec le matériel de clé de cet algorithme selon la RFC 7519.
En-tête
Charge utile
Signature
Algorithme
Jeton non valide
Comment utiliser l'analyseur JWT
Coller le jeton
Paste your JWT token in the input area
Décodage automatique
Token automatically decodes on paste
Examiner les parties
View header, payload, and signature data
Vérifier le statut
Vérifiez la validité du jeton et son expiration
Comprendre les jetons JWT
Qu'est-ce qu'un JWT ?
Un JSON Web Token (JWT) est un moyen compact et compatible URL de représenter des claims à transférer entre deux parties. Il se compose de trois parties — en-tête, payload et signature —, séparées par des points et encodées en base64url.
- • Header: Contains token type and signing algorithm
- • Payload: Contains claims or user data
- • Signature: Verifies token wasn't tampered with
- • Stateless: No server-side session storage needed
Pourquoi analyser les JWT ?
L'analyse des JWT est essentielle pour déboguer les problèmes d'authentification, vérifier le contenu des jetons, contrôler les dates d'expiration et comprendre quelles données sont transmises dans les jetons.
- • Debugging: Inspect token contents during development
- • Security: Verify token structure and claims
- • Expiration: Check token validity period
- • Development: Understand authentication flow
Référence des claims JWT standard
Noms de claims enregistrés définis par RFC 7519, que vous verrez dans presque tous les payloads de tokens.
| Claim | Nom complet | Signification |
|---|---|---|
| iss | Émetteur | Qui a créé et signé le token |
| sub | Sujet | De qui parle le token — généralement l'identifiant de l'utilisateur |
| aud | Public | À qui est destiné le token (un client ou une API) |
| exp | Expiration | Unix timestamp à partir duquel le token doit être rejeté |
| nbf | Pas avant | Unix timestamp avant lequel le token n'est pas valide |
| iat | Date d'émission | Unix timestamp de la création du token |
| jti | Identifiant JWT | Identifiant unique, utile pour les listes de révocation |
Algorithmes JWT courants
- • HS256 (HMAC + SHA-256) : Symétrique — un secret partagé signe et vérifie. Simple, mais quiconque détient le secret peut forging des tokens.
- • RS256 (RSA + SHA-256) : Asymétrique — la clé privée signe, la clé publique vérifie. Le choix standard pour les systèmes distribués.
- • ES256 (ECDSA + SHA-256) : Asymétrique comme RS256, mais avec des signatures bien plus courtes — un bon choix moderne par défaut.
- • aucun : Token non signé. Doit être rejeté par tout vérificateur sérieux ; historiquement à l'origine de vulnérabilités critiques de contournement.
Notes de sécurité
- • Ne collez jamais de tokens de production dans des outils inconnus. Cet analyseur s'exécute entièrement dans votre navigateur (vérifiez : il fonctionne hors ligne), mais ce n'est pas vrai de tous les sites.
- • Un JWT n'est pas chiffré. Le payload est seulement encodé en base64url — quiconque détient le token peut le lire. Ne stockez jamais de secrets dans les claims.
- • Décoder, ce n'est pas vérifier. Une structure d'apparence valide ne dit rien de la signature. La vérification exige la clé, qui ne quitte jamais votre serveur d'authentification.
- • Vérifiez exp côté serveur. Rejeter les tokens expirés est le rôle du vérificateur, pas du client.
Quand les développeurs utilisent un analyseur JWT
Débogage des réponses 401 et 403
Vérifiez si le jeton contenait réellement les scopes, rôles ou la date d'expiration attendus avant d'incriminer le serveur.
Inspecter les jetons OAuth et OIDC
Décodez un id_token ou access_token et confirmez que iss, aud et sub correspondent à la configuration de votre application.
Assistance et dépannage
Vérifiez depuis une capture d'écran les claims réellement reçus par un utilisateur, sans installer aucun outil local.
Comprendre le fonctionnement des JWT
Collez des jetons d'exemple et voyez comment s'articulent en-tête, payload et signature.
Décodage instantané
Décodage automatique du JWT au collage, avec sections codées par couleur.
100 % privé
Tout le décodage se fait dans votre navigateur. Les jetons ne quittent jamais votre appareil.
Entièrement gratuit
Aucune inscription ni limite. Analysez librement des jetons JWT à tout moment.
FAQ de l'analyseur JWT
Est-il sans risque de coller un JWT dans cet outil ?
Oui. Le décodage s'exécute entièrement dans votre navigateur, sans aucun appel réseau — vous pouvez le vérifier en vous déconnectant d'internet et en rechargeant la page. Malgré tout, évitez par principe de coller des tokens de production n'importe où.
L'analyse d'un JWT vérifie-t-elle sa signature ?
Non. L'analyse se contente de décoder le header et le payload en base64url. Vérifier la signature exige la clé de signature (secret HMAC ou clé publique), que seul votre serveur d'authentification détient.
Pourquoi n'importe qui peut-il lire le payload de mon JWT ?
Les payloads des JWT sont encodés, pas chiffrés. Quiconque détient le token peut le décoder et lire les claims — c'est voulu par conception. Ne stockez jamais de secrets ni de données sensibles dans le payload d'un JWT.
Comment savoir quand un token expire ?
Vérifiez le claim exp — un Unix timestamp à partir duquel le token doit être rejeté. Cet analyseur met automatiquement en évidence le statut du token (actif, expiré ou pas encore valide) selon exp et nbf.
Quelle est la différence entre HS256 et RS256 ?
HS256 est symétrique : un secret partagé sert à la fois à signer et à vérifier, donc quiconque peut vérifier les jetons peut aussi les falsifier. RS256 est asymétrique : une clé privée signe et une clé publique vérifie, ce qui est plus sûr lorsque plusieurs services doivent valider les jetons. Préférez RS256 ou ES256, sauf raison spécifique contraire.
L'en-tête de mon jeton indique "alg": "none" — est-ce un problème ?
Cela signifie que le jeton n'est pas signé. C'est une structure JWT valide, mais un vérificateur ne doit jamais l'accepter : la vulnérabilité JWT classique était l'attaquant qui mettait alg à none pour contourner les vérifications de signature. Si votre backend accepte des jetons non signés, considérez-le comme un bug de sécurité.
Boostez votre productivité avec des outils d'analyse et de mise en forme de texte