Décodeur JWT

Comment décoder un JWT

Un JSON Web Token n'est rien d'autre que trois chaînes base64url reliées par des points. Le décoder consiste à reconvertir les deux premières chaînes en JSON lisible afin d'inspecter l'en-tête et les revendications sans logiciel particulier. Suivez ces étapes.

1. Collez le jeton. Copiez le jeton complet — il est long — et collez-le dans le champ. Par exemple, le jeton eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c se décode en un en-tête et une charge utile qui sont tous deux du JSON lisible.

2. Lisez l'en-tête. L'en-tête indique l'algorithme qui a signé le jeton ainsi que son type. Dans l'exemple ci-dessus, il s'agit de {"alg":"HS256","typ":"JWT"}, ce qui signifie que l'émetteur a utilisé un secret partagé HMAC-SHA256. Si vous voyez « alg »:« none » ou un algorithme inattendu, considérez le jeton comme suspect.

3. Inspectez la charge utile. La charge utile porte les revendications : les champs enregistrés comme sub, iat et exp, plus des champs applicatifs comme name ou role. Dans l'exemple, le sujet est 1234567890, le nom est Jane Doe et le rôle est admin ; ce jeton décrit donc un utilisateur précis et son niveau d'autorisation.

4. Vérifiez les horodatages. La revendication iat 1516239022 correspond au 18 janvier 2018 à 01:30:22 UTC, et exp 1516242622 se situe exactement une heure plus tard. L'outil affiche les deux en heure locale et indique d'un coup d'œil si le jeton est expiré ou encore valide, ce qui est bien plus sûr que de comparer de grands entiers à l'œil nu.

5. Confirmez la structure en trois parties. Si le nombre de segments n'est pas trois, si un segment n'est pas un base64url valide, ou si le texte décodé n'est pas du JSON, l'outil affiche une erreur précise et localisée au lieu de deviner. Corrigez votre copie et relancez le décodage.

6. Rappelez-vous ce que le décodage ne fait pas. Cette page ne vérifie jamais la signature, l'émetteur ni l'audience. Utilisez-la pour comprendre et déboguer un jeton, puis vérifiez-le correctement dans votre propre service avant de faire confiance à une revendication.

Qu'est-ce qu'un JWT, et pourquoi décoder n'est pas vérifier ?

Un JSON Web Token, défini par la RFC 7519, est un moyen compact et sûr pour les URL de représenter des revendications entre deux parties. Il comporte trois parties séparées par des points. L'en-tête est un petit objet JSON décrivant le jeton, généralement l'algorithme de signature (alg) et le type (typ). La charge utile est un objet JSON de revendications — des affirmations sur l'utilisateur ou la session. La signature est une valeur cryptographique calculée à partir des deux premières parties. Chaque partie est encodée en base64url, une variante du base64 qui remplace + par - et / par _, et supprime le remplissage =, afin que le jeton circule sans risque dans les URL, les en-têtes HTTP et les cookies. Le base64url est un encodage, pas un chiffrement. Quiconque possède le jeton peut le décoder en une fraction de seconde, ce qui explique pourquoi un JWT ne doit jamais contenir de secret. L'en-tête et la charge utile sont lisibles par le client et par quiconque intercepte le jeton ; seule la signature dépend d'une clé. C'est cette signature qui garantit l'intégrité : l'émetteur la calcule sur en-tête.chargeutile avec un secret ou une clé privée, et le destinataire la recalcule et la compare. Si un seul caractère de la charge utile change, la signature ne correspond plus et un serveur correctement implémenté rejette le jeton. La distinction essentielle est donc celle entre décoder et vérifier. Décoder, ce que fait cet outil, est un simple analyse syntaxique sans clé, qui ne prouve rien. Vérifier exige la clé de l'émetteur, confirme la signature, et contrôle normalement aussi que le jeton n'a pas expiré, que l'émetteur (iss) et l'audience (aud) sont ceux attendus, et que l'algorithme fait partie de ceux que vous autorisez. Une attaque fréquente consiste à supprimer la signature et à forcer alg à « none », ou à remplacer RS256 par HS256 pour amener un serveur à traiter une clé publique comme un secret HMAC. Un décodeur affichera volontiers un tel jeton falsifié ; seul un vérificateur le rejette. Servez-vous du décodage pour inspecter et déboguer, et de la vérification pour accorder l'accès.

Applications courantes

1. Déboguer un flux d'authentification. Vous vous connectez et recevez « 401 Unauthorized » à chaque requête. Décoder le jeton d'accès révèle {"exp":1516242622}, et vous constatez que l'expiration date de 2018 : l'horloge du serveur ou la durée de vie du jeton est erronée. Aucune clé n'est nécessaire.

2. Lire l'identité que représente un jeton. Un ingénieur support colle le jeton d'un client et voit {"sub":"1234567890","role":"admin","scope":"orders:read"} pour comprendre les permissions que le client croit détenir, sans toucher à la base de production.

3. Contrôler la durée de vie pendant un incident. Si les jetons sont censés vivre une heure mais qu'un échantillon montre iat et exp à soixante secondes d'écart, la logique de rafraîchissement ou la configuration est erronée, et le décodeur le révèle instantanément.

4. Inspecter des jetons d'identité tiers. OpenID Connect renvoie un id_token contenant des champs comme iss, aud et email. Le décoder montre quel fournisseur l'a émis et à quel client il est destiné, ce qui est utile lors de l'intégration d'un nouveau SSO.

5. Enseignement et revue de code. Lors d'une revue d'un changement d'authentification, coller un JWT d'exemple dans le décodeur montre immédiatement à toute l'équipe la différence entre un jeton qui ne porte qu'un identifiant utilisateur et un jeton qui porte toute une liste de permissions.

6. Auditer les revendications pour la vie privée. Le décodage révèle si des données sensibles comme une adresse e-mail ou un rôle interne ont fuité dans la charge utile, car tout ce qu'elle contient est visible par le client et par quiconque capture le jeton.

Pièges de sécurité fréquents

Le premier piège est de faire confiance à la charge utile. Comme le base64url est réversible, une revendication décodée telle que « role »:« admin » n'est qu'une affirmation, pas un fait, tant que la signature n'est pas vérifiée. Le deuxième est la confusion « alg »:« none » : un attaquant peut reconstruire l'en-tête sans signature, et un serveur qui n'impose pas l'algorithme attendu peut l'accepter. Le troisième est la rétrogradation RS256 vers HS256, où un serveur est amené à vérifier un jeton asymétrique en utilisant la clé publique comme secret HMAC. Le quatrième est de traiter un jeton comme une session : parce qu'un JWT est autonome, il reste valide jusqu'à exp même après une déconnexion, sauf si vous ajoutez une liste de révocation par jti ou des durées de vie courtes. Enfin, ne stockez jamais un JWT dans localStorage si une faille XSS est possible ; un cookie httpOnly et Secure est plus sûr. Ce décodeur ne fait volontairement aucun de ces contrôles, raison pour laquelle vous devez vérifier ailleurs.

JWT ou jeton opaque ?

Un jeton opaque est une chaîne aléatoire dont la signification réside dans une base de données ; le serveur la consulte, ce qui permet une révocation instantanée et ne révèle rien en soi. Un JWT est autonome : le serveur peut lui faire confiance en vérifiant une signature, sans consultation, ce qui passe à l'échelle dans les microservices mais rend la révocation plus difficile. Ce compromis résume tout. Utilisez des JWT lorsque de nombreux services doivent valider un jeton indépendamment, lorsque vous avez besoin d'identifiants de courte durée, ou lorsqu'un tiers doit vérifier votre jeton. Utilisez des jetons opaques lorsque la révocation instantanée, une taille minimale ou le maintien de tout l'état côté serveur importe davantage. De nombreux systèmes combinent les deux : un jeton d'accès JWT de courte durée pour la vitesse, plus un jeton de rafraîchissement opaque stocké et révocable dans la base. Décoder un JWT rend sa nature autonome évidente, puisque chaque revendication est présente dans la chaîne.

Revendications enregistrées et privées

La RFC 7519 réserve sept noms de revendications pour que les différents systèmes s'accordent sur leur sens : iss, sub, aud, exp, nbf, iat et jti. Tout le reste est une revendication privée choisie par l'émetteur, comme role, scope, tenant ou email. Les revendications enregistrées doivent être traitées par tout destinataire ; les revendications privées n'ont de sens que pour les applications qui les définissent. Deux conséquences pratiques en découlent. Premièrement, vérifiez toujours exp et aud, même si votre framework s'en charge, car un jeton émis pour une API ne doit pas être accepté par une autre. Deuxièmement, gardez les revendications privées petites et non sensibles : un identifiant utilisateur numérique convient, mais un profil complet ou un code de réinitialisation de mot de passe n'a rien à faire dans un jeton que tout client peut lire.

Utilitaires Connexes

• Formateur & Validateur JSON en Ligne
• Encodeur & Décodeur Base64 en Ligne
• Générateur de Mots de Passe — Mots de Passe Forts
• Encodeur & Décodeur d'URL — Encodage Pourcent
• Générateur d'UUID — Créer des UUID v4 en Ligne
• Supprimer les Lignes en Double — Outil Gratuit