Décodeur JWT
Ce Qui Est
JWT Decoder est un outil de sécurité et de développement qui analyse et affiche le contenu des jetons Web JSON (JWT) — un standard ouvert (RFC 7519) pour la transmission d'informations entre les parties sous la forme d'un objet JSON compact et sécurisé par URL. Les JWT se composent de trois composants séparés par des points: l'en-tête (spécifie le type de jeton et l'algorithme de signature), la charge utile (contient les revendications ou les données et métadonnées utilisateur réelles) et la signature (vérifie que le jeton n'a pas été modifié en transit).
Notre décodeur décompose instantanément n'importe quel JWT en ses trois parties codées en Base64Url, décode chaque composant en JSON et les affiche dans une vue structurée et en surbrillance syntaxique avec des horodatages lisibles par l'homme convertissant les heures d'époque Unix en revendications exp (expiration), iat (émis à) et nbf (pas avant). L'outil valide la structure des jetons (trois parties séparées par des points, encodage Base64Url valide, JSON valide dans les parties décodées) et met en évidence les problèmes potentiels tels que les jetons expirés ou les algorithmes inhabituels.
Comment utiliser
- Collez la chaîne JWT complète (y compris les trois sections séparées par des points) dans le champ de saisie JWT ou utilisez l'option de téléchargement de fichier pour charger un jeton à partir d'un fichier
- Cliquez sur le bouton Décoder JWT pour analyser et afficher instantanément l'en-tête du jeton, les composants de signature de charge utile dans des panneaux séparés
- Examinez le panneau d'en-tête indiquant l'algorithme et le type de jeton utilisés pour signer ce JWT, y compris les champs alg, typ et kid
- Examinez le panneau de charge utile affichant toutes les revendications (données utilisateur, heure d'expiration, émetteur, audience, étendues) avec un formatage de date lisible par l'homme pour les revendications d'horodatage
- Vérifiez le panneau d'état de la signature pour vérifier si le jeton a expiré (en fonction de la revendication exp) et l'algorithme utilisé pour détecter les problèmes de sécurité potentiels
Exemples
Entrée: JWT: ceJhbGciOiJIUzI1NiJ9.Oui, oui, oui, oui, oui, oui, oui, oui, oui, oui, oui, oui, oui, oui.signature
Processus:
Split by . → Base64-decode header → Base64-decode payloadRésultat: En-tête: {alg: HS256}, Charge utile: {sub: 1234}
Entrée: JWT avec réclamation d'exp
Processus:
Decode payload → Extract exp timestamp → Check expiryRésultat: Le jeton expire: 2026-12-31 (expire dans 170 jours)
Recherches Connexes
Les gens recherchent aussi : décodeur JWT, décoder les JWT, inspecteur JWT, décodage des jetons jwt, jeton web json, analyseur jwt.
décodeur JWTdécoder les JWTinspecteur JWTdécodage des jetons jwtjeton web jsonanalyseur jwtdébogueur jwtvérifier jwt
Questions Fréquemment Posées
Qu'est-ce qu'un JWT et comment est-il structuré?
JWT (JSON Web Token) est un standard ouvert (RFC 7519) pour la transmission sécurisée d'informations entre parties en tant qu'objet JSON. Il se compose de trois parties séparées par des points: L'en-tête contient des métadonnées sur le jeton, en particulier l'algorithme de signature (tel que HS256, RS256, ES256) et le type de jeton (toujours JWT), encodé en Base64Url JSON. La charge utile contient les revendications (déclarations sur une entité, généralement l'utilisateur, et des données supplémentaires) telles que sub (objet/ID utilisateur), exp (horodatage d'expiration), iat (émis à), aud (audience), iss (émetteur), et toutes les revendications personnalisées que votre application ajoute. La signature est calculée en hachant l'en-tête codé et la charge utile avec une clé secrète (pour les algorithmes HMAC) ou une clé privée (pour les algorithmes RSA/ECDSA), garantissant que le jeton ne peut pas être modifié sans détection. Le jeton final ressemble à ceci : eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U.
Est-il sûr de décoder un JWT à l'aide d'un outil en ligne?
Le décodage est sans danger, car l'en-tête et la charge utile d'un JWT ne sont PAS chiffrés : ils sont simplement encodés en Base64Url (comme le base64, mais compatible avec les URL), ce qui signifie que toute personne qui possède le jeton peut lire son contenu. C'est voulu : par défaut, les JWT sont signés, pas chiffrés. La signature ne garantit que l'intégrité, pas la confidentialité. En revanche, vous ne devez JAMAIS partager des jetons contenant des données sensibles (mots de passe, données personnelles, clés d'API) dans un outil de décodage, quel qu'il soit. Le risque de sécurité ne vient pas du décodage lui-même, mais du fait d'exposer le jeton à des tiers. Notre outil traite tout côté client, dans votre navigateur : le jeton n'est jamais envoyé à un serveur, ce qui préserve la confidentialité. Si votre application exige des jetons confidentiels, envisagez JWE (JSON Web Encryption), qui chiffre la charge utile, ou veillez à ce que les JWT ne contiennent aucune information sensible.
Quels algorithmes JWT sont pris en charge et comment interpréter l'en-tête?
Les algorithmes courants incluent: HS256 (HMAC SHA-256) utilise une clé secrète symétrique pour la signature et la vérification — la même clé sert à signer et à vérifier; HS384 et HS512 utilisent des sorties de hachage plus importantes. RS256 (RSA SHA-256) utilise une paire de clés asymétrique: une clé privée signe, une clé publique vérifie — utilisée par les fournisseurs OAuth (Auth0, Okta); RS384 et RS512 sont les mêmes avec des hachages plus importants. ES256 (ECDSA P-256), ES384, ES512 utilisent la cryptographie à courbe elliptique pour des signatures plus courtes. Aucun signifie un jeton non signé-rejetez-les en production. L'en-tête inclut aussi parfois kid (key ID) pour préciser quelle clé de signature a été utilisée lorsque plusieurs clés sont disponibles. Des jetons utilisant l'algorithme « none » ont déjà été exploités par le passé.
Comment puis-je vérifier la signature d'un JWT décodé?
Notre décodeur montre les composants décodés et la validité structurelle du jeton mais ne peut pas vérifier complètement la signature car la vérification nécessite le secret de signature (pour les algorithmes symétriques comme HS256) ou la clé publique (pour les algorithmes asymétriques comme RS256). Pour vérifier: pour les algorithmes symétriques, entrez le secret partagé dans notre champ de vérification de signature et l'outil recalculera la signature et la comparera à la signature du jeton, indiquant une correspondance ou une incompatibilité. Pour les algorithmes asymétriques, fournissez la clé publique (format PEM) et l'outil effectue une vérification cryptographique. La vérification de la signature confirme deux choses: le jeton a été signé par l'émetteur attendu (qui détient la clé privée/secrète) et le contenu du jeton n'a pas été modifié depuis la signature. Pour la validation des jetons de production, vérifiez toujours les signatures dans votre middleware d'autorisation.
Quelles sont les revendications communes de JWT et que signifient-elles?
Les revendications JWT standard (définies dans la RFC 7519) incluent : iss (émetteur) identifie le principal qui a émis le JWT, généralement l'URL du serveur d'authentification (comme https://auth.example.com) ; sub (sujet) identifie le principal qui est le sujet du JWT, généralement l'ID utilisateur ; aud (audience) identifie les destinataires auxquels le JWT est destiné, généralement l'identifiant de votre application ; exp (date d'expiration) est l'horodatage après lequel le JWT ne doit plus être accepté, exprimé en secondes d'époque Unix ; nbf (pas avant) est l'horodatage avant lequel le JWT ne doit pas être accepté ; iat (émis à) identifie l'heure à laquelle le JWT a été émis, ce qui sert à déterminer l'âge du jeton ; jti (ID JWT) fournit un identifiant unique pour le JWT, utilisé pour empêcher les attaques par rejeu. L'expiration est la revendication la plus critique : vérifiez toujours exp dans votre middleware de validation des jetons pour rejeter les jetons expirés.