Decodeur JWT

Ces termes font référence à l'algorithme de signature dans l'en-tête du JWT. HS256 (HMAC-SHA256) utilise un secret partagé — la même clé est utilisée pour signer et pour vérifier. Cela signifie que quiconque possède la clé peut également créer des jetons valides. RS256 (RSA-SHA256) utilise une paire de clés publique/privée — le serveur signe avec une clé privée et publie une clé publique pour la vérification. RS256 est plus sécurisé dans les systèmes distribués car les vérificateurs n'ont besoin que de la clé publique et ne peuvent pas falsifier les jetons. Ce décodeur affiche le champ alg mais ne peut vérifier aucun des algorithmes — il se contente de lire ce qui se trouve à l'intérieur.

Non. La vérification de la signature nécessite le secret (pour les algorithmes HMAC) ou la clé publique (pour les algorithmes RSA/EC) qui a été utilisé pour signer le jeton. Cet outil ne fait que décoder — il décode en Base64url l'en-tête et la charge utile pour vous montrer le contenu sans aucune vérification cryptographique. La section de la signature est affichée telle quelle mais n'est pas validée. Pour vérifier une signature, utilisez votre bibliothèque JWT côté serveur (jsonwebtoken pour Node.js, PyJWT pour Python, java-jwt pour Java, etc.).

Les revendications enregistrées sont des champs de charge utile standardisés définis dans la RFC 7519. Les sept revendications standards : iss (issuer) — qui a émis le jeton ; sub (subject) — le sujet du jeton (généralement un ID utilisateur) ; aud (audience) — les destinataires prévus ; exp (expiration time) — l'horodatage Unix après lequel le jeton est invalide ; nbf (not before) — l'horodatage Unix avant lequel le jeton ne doit pas être accepté ; iat (issued at) — l'horodatage Unix de la création du jeton ; jti (JWT ID) — identifiant unique pour le jeton. Cet outil convertit exp, nbf et iat des horodatages Unix vers des dates lisibles par l'homme.

Le décodeur vérifie la revendication exp par rapport à l'heure actuelle et marque clairement les jetons expirés. Un jeton expiré signifie que l'API le rejettera avec une réponse 401 Unauthorized — vous devez utiliser votre refresh token pour obtenir un nouveau access token (si votre système d'authentification prend en charge les refresh tokens) ou vous reconnecter. Si vous débuggez une erreur de "jeton expiré" provenant d'une API, ce décodeur vous montrera exactement quand le jeton a expiré et quand il a été émis.

Le champ alg dans l'en-tête est affiché décodé — si un jeton possède "alg":"none", vous le verrez. C'est une vulnérabilité JWT connue : certaines premières implémentations acceptaient des jetons sans signature (alg:none), permettant aux attaquants de falsifier des charges utiles arbitraires. Toute bibliothèque JWT correctement implémentée rejette les jetons alg:none par défaut. Si vous voyez alg:none dans un jeton provenant de votre propre système, c'est un bug de sécurité critique qui nécessite une attention immédiate.

Non. Tout le décodage se déroule dans votre navigateur en utilisant JavaScript — le décodage Base64url ne nécessite aucun calcul côté serveur. Vos jetons JWT, y compris les ID utilisateurs, les rôles ou les données de session qu'ils contiennent, ne quittent jamais votre appareil. Cela dit, soyez prudent lors du collage de jetons JWT de production dans un outil en ligne — même celui-ci. Pour débugger des problèmes d'authentification en production, utilisez plutôt l'onglet réseau des outils de développement de votre navigateur ou votre système de journalisation.

Un JWT valide doit avoir exactement deux points séparant trois sections encodées en Base64url. Si un jeton n'a pas de points, ce n'est pas un JWT — il peut s'agir d'un jeton opaque (un identifiant aléatoire nécessitant une recherche côté serveur) plutôt que d'un JWT autonome. Certains systèmes utilisent les deux types : un refresh token opaque et un access token JWT. Si vous recevez une erreur "Invalid JWT format", vérifiez que vous collez bien l'access token (qui devrait commencer par "ey") et non le refresh token.