1
Coller le token
L’outil sépare les trois segments Base64URL et affiche le Header et le Payload JSON en texte brut.
DEVELOP.03 JWT DECODER
Décodeur JWT
L’entrée du token, Header, Payload et les claims temporels restent visibles. JSON et Claims partagent des onglets, et la vérification HMAC apparaît seulement lorsqu’elle est nécessaire.
Coller un JWT
En attente d’un token
Header
Payload
ClaimValeurSignification
Signature et état temporel
§ 01
Inspecter un JWT en toute sécurité
2
Contrôler les claims temporels
Ouvrez la vue Claims pour voir les dates locales et l’état relatif de exp, nbf et iat, y compris les tokens expirés ou pas encore actifs.
3
Vérifier si possible
Pour les algorithmes HS, saisissez le secret partagé afin de vérifier localement. Un décodage réussi ne rend pas une signature fiable.
§ 02
Lisible ne signifie pas fiable
Un JWT comporte trois segments séparés par des points. Header indique l’algorithme et le type, Payload contient les claims et Signature vérifie que les deux premiers segments n’ont pas changé. Les deux premiers sont encodés en Base64URL et peuvent donc être lus sans clé.
Une erreur fréquente en débogage consiste à voir un Payload plausible et à supposer le token valide. Une autorisation réelle doit vérifier côté serveur la signature, l’émetteur, l’audience, la fenêtre temporelle et une liste d’algorithmes autorisés.
§ 03
Claims enregistrés courants
Claim
Signification
À vérifier
issÉmetteur
Correspond au service d’identité attendu
subSujet / utilisateur
Identifie le sujet prévu
audAudience
Inclut le service actuel
expExpiration
L’heure actuelle est antérieure à cette valeur
nbfValide à partir du
L’heure actuelle n’est pas antérieure à cette valeur
iatÉmis le
Se trouve dans une fenêtre raisonnable
jtiID unique du token
Peut contribuer à la révocation et à la protection contre la relecture
§ 04
Questions fréquentes
Q1Quelle différence entre décoder et vérifier un JWT ?
Décoder restaure simplement le texte Base64URL en JSON et ne nécessite aucune clé. Vérifier utilise le secret ou la clé publique correcte pour confirmer que le contenu est intact et provient d’un émetteur de confiance.
Q2Le payload est-il chiffré ?
Dans un JWT classique, Header et Payload sont encodés, pas chiffrés. N’y placez pas de mots de passe, clés privées ou autres secrets qui ne devraient pas être visibles par le client.
Q3Que signifient exp, nbf et iat ?
exp est l’expiration, nbf le début de validité et iat la date d’émission. Ce sont généralement des horodatages Unix en secondes.
Q4Pourquoi seuls les algorithmes HS sont-ils vérifiés ici ?
HS256, HS384 et HS512 utilisent un secret partagé saisi explicitement. RS et ES nécessitent des formats de clés publiques et des paramètres de courbe ; cette page les laisse donc en décodage seul.
Q5Les tokens et les secrets sont-ils enregistrés ?
Non. Le décodage et la vérification HMAC se déroulent uniquement dans la mémoire de la page actuelle, sans envoi au serveur ni stockage navigateur.