Comment décoder un JWT et inspecter ses réclamations en toute sécurité
Réponse rapide
Un JWT est constitué de trois chaînes Base64URL reliées par des points : header.payload.signature. Décodez l'en-tête et la charge utile avec le décodage Base64URL pour inspecter les revendications, mais le décodage ne lit que les données, il ne vérifie pas l'authenticité. Vérifiez toujours la signature sur le serveur avant de faire confiance à toute réclamation. Utilisez notre décodeur JWT pour inspecter les jetons dans votre navigateur.
Introduction
Un jeton Web JSON (JWT, RFC 7519) est un format de jeton compact et sécurisé URL utilisé pour l'authentification et l'autorisation. Il comporte trois parties codées en Base64URL séparées par des points : header.payload.signature. L'en-tête décrit l'algorithme, la charge utile contient des réclamations (identifiant utilisateur, rôles, expiration) et la signature prouve que le jeton a été émis par une partie de confiance. Surtout, l’en-tête et la charge utile sont codés et non chiffrés : tout le monde peut les lire.
Pas à pas
-
Divisez le jeton en trois parties
Un JWT ressemble à xxxxx.yyyyy.zzzzz. Divisez le caractère point pour obtenir l'en-tête (partie 0), la charge utile (partie 1) et la signature (partie 2). S’il n’y a pas exactement trois parties, le jeton est mal formé.
-
Base64URL-décode l'en-tête
L'en-tête est un objet JSON codé en Base64URL comme {"alg": "HS256", "typ": JWT"}. Base64URL utilise - et _ au lieu de + et / et omet le remplissage. Décodez-le, puis JSON.parse pour lire l'algorithme et tapez. Notre décodeur JWT le fait automatiquement.
-
Base64URL-décode la charge utile (revendications)
La charge utile est un objet de réclamation JSON. Les revendications enregistrées incluent iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis à) et jti (identifiant du jeton). Les revendications privées sont spécifiques à l'application (par exemple, rôle, adresse e-mail). Décodez et inspectez, mais ne faites pas confiance jusqu'à ce que cela soit vérifié.
-
Vérifiez les réclamations d'expiration et non-avant
exp et nbf sont des horodatages Unix (secondes). Si l'heure actuelle est dépassée exp, le jeton a expiré et doit être rejeté. Si l'heure actuelle est antérieure à nbf, le jeton n'est pas encore valide. Vérifiez-les côté client pour l'UX, mais appliquez-les côté serveur pour des raisons de sécurité.
-
Vérifier la signature sur le serveur (jamais côté client)
La signature est HMAC-SHA256 (secret, header.payload) pour HS256, ou signature RSA/ECDSA pour RS256/ES256. La vérification nécessite la clé secrète ou publique, qui ne doit jamais parvenir au navigateur. Utilisez une bibliothèque comme jsonwebtoken (Node) ou jose pour vérifier – n'écrivez jamais votre propre crypto.
Exemples
Un JWT typique (trois parties)
Saisir: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
Sortir: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Charge utile décodée avec revendications standard
Saisir: Charge utile d'un véritable jeton d'authentification
Sortir: {"sub":"user-42","iss":"freeonlinetoolsgo.com","exp":1767229200,"iat":1767225600,"role":"admin"}
Détection de jeton expiré
Saisir: exp : 1609459200 (01/01/2021) vérifié le 28/08/2026
Sortir: Token is expired —current time (1767225600) > exp (1609459200). Reject and prompt re-login.
Problèmes courants
- Traiter le décodage comme une vérification : n'importe qui peut créer un JWT avec n'importe quelle affirmation et une fausse signature. Le décodage lit la charge utile mais ne prouve rien. Vérifiez toujours la signature avec la clé secrète/publique sur le serveur avant de faire confiance aux réclamations.
- Utilisation de l'algorithme « none » : la spécification JWT autorise alg: none pour les jetons non sécurisés. Si votre vérificateur accepte alg: none, un attaquant peut falsifier des jetons. Configurez votre bibliothèque pour n’en rejeter aucun et mettez sur liste blanche les algorithmes attendus.
- Stockage des JWT dans localStorage : XSS peut lire localStorage et exfiltrer les jetons. Préférez les cookies httpOnly, Secure, SameSite=Strict pour les jetons de session, ou les jetons en mémoire de courte durée avec un cookie de jeton d'actualisation.
- Ne pas vérifier exp/aud/iss : un token volé est valide jusqu'à son expiration. Vérifiez toujours exp (expiration), aud (public cible) et iss (émetteur) sur chaque demande pour empêcher la réexécution du jeton entre les services.
Conseils
- Utilisez des jetons d'accès de courte durée (15 minutes) ainsi que des jetons d'actualisation de longue durée : cela limite la fenêtre en cas de vol d'un jeton d'accès.
- Préférez RS256 (asymétrique) à HS256 (symétrique) lorsque plusieurs services vérifient les jetons : chaque service obtient la clé publique, et seul l'émetteur possède la clé privée.
- Utilisez notre décodeur JWT pendant le développement pour inspecter ce que le serveur émet : il affiche l'en-tête décodé, la charge utile et un résumé de réclamation lisible par l'homme sans envoyer le jeton nulle part.
- Ne placez jamais de données sensibles (mots de passe, informations personnelles) dans une charge utile JWT : elles sont codées en Base64, non cryptées, et toute personne interceptant le jeton peut lire chaque réclamation.