Que faire quand le décodeur JWT signale un token invalide ? Commençons par la conclusion
Face à une erreur du décodeur JWT, ne vous précipitez pas pour modifier le code. Dans plus de neuf cas sur dix, un « token invalide » ne vient pas d'un problème d'algorithme de chiffrement, mais d'un token incomplet, de caractères parasites collés avec, ou du fait que vous confondez « décodage » et « vérification ». En suivant l'ordre ci-dessous, vous localiserez généralement le problème en quelques minutes.
Le décodeur JWT n'est qu'un outil d'analyse local : il restaure les trois segments du token en en-tête et charge utile lisibles. Il ne vérifie pas la signature et ne détermine pas si le token est expiré.
Comment utiliser le décodeur JWT : analyse en trois étapes
Un JWT valide se compose de trois segments séparés par deux points anglais : en-tête, charge utile, signature. Si un segment manque, l'analyse échoue.
- Récupérez la chaîne de token complète, généralement présente dans le champ
Authorizationde l'en-tête de requête, au formatBearer. - Retirez le préfixe
Beareret les espaces superflus, ne gardez que le token lui-même. - Collez-le dans le décodeur JWT ; l'outil restaurera l'en-tête et la charge utile localement dans le navigateur.
Dans le résultat, vous verrez des champs comme alg, exp, sub. exp est l'horodatage d'expiration, en secondes.
Erreurs fréquentes lors de l'utilisation du décodeur JWT
L'erreur la plus courante consiste à coller tout l'en-tête de requête, y compris Bearer et les sauts de ligne. Les sauts de ligne sont invisibles à l'œil nu, mais font échouer directement le décodage base64url.
La deuxième erreur est de tronquer la fin lors de la copie. Le token est long, et les messageries ou terminaux insèrent souvent des sauts de ligne ou des points de suspension au milieu.
La troisième erreur est d'utiliser un collage en texte enrichi formaté, où les guillemets sont automatiquement convertis en caractères pleine largeur chinois.
Que faire quand le décodeur JWT signale une erreur : vérifier ces cinq catégories de causes
Ci-dessous, classées par fréquence décroissante, vous pouvez les vérifier une par une.
- Nombre de segments incorrect : le token doit comporter exactement deux séparateurs à points ; un de plus ou de moins provoquera une erreur.
- Jeu de caractères illégal : base64url n'autorise que les lettres, les chiffres,
-et_; la présence de+,/,=ou d'espaces doit alerter. - Caractères blancs : espaces en début et fin, tabulations, sauts de ligne perturbent l'analyse.
- Token tronqué : longueur manifestement trop courte, ou fin qui n'est pas un segment complet.
- Contenu qui n'est pas un JWT : par exemple, certaines API renvoient des jetons opaques, impossibles à analyser.
Pourquoi retirer le préfixe Bearer résout la plupart des erreurs
Parce que le décodeur a besoin du token pur, tandis que Bearer fait partie du protocole de transport et non de la structure du token. Mélangés, le premier segment n'est plus une chaîne base64url valide.
Si vous rencontrez à répétition des erreurs dans un scénario de débogage d'API avec le décodeur JWT, il est conseillé d'enregistrer d'abord la chaîne brute dans un fichier texte pur, de retirer les espaces en début et fin, puis de coller : cela élimine les interférences dues aux retours à la ligne automatiques de l'éditeur.
Différence entre décodeur JWT et vérification
C'est le point le plus souvent confondu, et la source de nombreux « faux positifs ».
Décoder consiste simplement à restaurer l'encodage base64url en clair ; toute chaîne conforme au format peut être décodée, sans clé. Vérifier consiste à valider que la signature a été générée par le détenteur de la clé, et à contrôler l'expiration, l'émetteur, l'audience et autres déclarations.
Ainsi, un décodage réussi ne signifie pas que le token est valide. Un token falsifié peut tout de même être décodé, mais la vérification échouera à coup sûr.
Inversement, un échec de décodage indique généralement que les données ont été altérées lors du transport ou de la copie, et non que la signature pose problème. Distinguer ces deux aspects vous fera gagner beaucoup de temps de dépannage.
Décodeur JWT et gros fichiers : que faire quand le token est très long
Un JWT a une limite de taille, mais lorsque la charge utile contient de nombreuses déclarations personnalisées, le token devient très long, fréquent dans les cas de listes de permissions ou de profils utilisateur.
Un token long pose deux problèmes. D'une part, il est facilement coupé automatiquement par les outils lors de la copie ; d'autre part, certains terminaux et systèmes de journalisation tronquent les chaînes trop longues.
Recommandations :
- Écrivez d'abord le token dans un fichier via une commande ou un script, puis vérifiez segment par segment qu'il est complet.
- Assurez-vous qu'aucun saut de ligne ne s'est glissé, beaucoup d'erreurs viennent de là.
- Si la charge utile est vraiment trop volumineuse, envisagez de réduire les champs de déclaration pour ne garder que l'essentiel.
À noter : plus le token est long, plus la surcharge à chaque requête est importante. Ce n'est pas qu'un problème de décodage, cela affecte aussi les performances de l'API.
Décodeur JWT mobile : points clés du dépannage sur mobile
Sur mobile, le dépannage des tokens se heurte surtout à la copie et au collage.
La sélection par appui long sur mobile omet facilement quelques caractères au début ou à la fin. Privilégiez « Tout sélectionner » plutôt que le glissement manuel de la zone de sélection.
De plus, certains claviers remplacent automatiquement les guillemets anglais par des guillemets chinois, ou ajoutent un espace après une majuscule. Passez en saisie anglaise avant de coller.
Si votre page d'outil s'affiche correctement sur mobile, collez directement : l'analyse se fait localement, le token ne quitte pas votre appareil. C'est particulièrement important lors du dépannage de tokens en production.
Questions fréquentes
Le décodage réussit mais l'API renvoie toujours 401 : est-ce un problème du décodeur
Non. Un 401 signifie généralement que la vérification côté serveur a échoué : signature non concordante, token expiré, ou émetteur et audience incompatibles. Le décodeur ne fait que restaurer le contenu, il ne participe pas à la vérification.
Pourquoi y a-t-il des caractères illisibles dans le token
Le plus souvent, il s'agit d'un jeu de caractères illégal ou de caractères cachés. base64url utilise une plage de caractères très restreinte ; dès qu'un espace, un saut de ligne ou un symbole pleine largeur s'y glisse, le résultat est illisible.
Pourquoi le même token se décodait hier mais pas aujourd'hui
La chaîne du token elle-même ne change pas. Il est plus probable que le contenu copié cette fois diffère de la précédente : un saut de ligne en plus, ou un champ renvoyé par l'API source qui a changé.
Le décodeur peut-il voir la clé correspondant à la signature
Non. La signature est le résultat d'une opération à sens unique ; on ne peut pas en déduire la clé. Toute affirmation prétendant restaurer la clé depuis le token est douteuse.
Comment lire l'heure d'expiration
exp et iat sont des horodatages Unix, en secondes, à convertir en date pour comparaison. Notez qu'il s'agit de l'heure UTC.
Pour conclure
Pour dépanner une erreur du décodeur JWT, l'essentiel tient en trois étapes : vérifier que le token est complet, retirer les caractères non liés au token, distinguer décodage et vérification. En maîtrisant ces trois points, la grande majorité des erreurs disparaîtra. Pour une vérification rapide, utilisez un outil exécuté localement dans le navigateur pour restaurer le contenu du token sans avoir à téléverser de données.