UltKit

Décodeur JWT

Collez un JSON Web Token pour lire son en-tête et son payload en JSON formaté, avec les dates d’expiration et d’émission affichées en clair et une indication sur la validité actuelle du jeton. Le décodage se fait entièrement dans votre navigateur, ce qui compte lorsque le jeton est un identifiant actif.

0 caractères · 0 mots · 0 lignes

0 caractères · 0 mots · 0 lignes

Fonctionne entièrement dans cet onglet du navigateur. Votre texte n’est jamais envoyé ni stocké.

Revendications enregistrées

Les sept noms de revendications définis dans la RFC 7519 §4.1. Toutes sont facultatives ; les heures sont exprimées en secondes depuis le 1970-01-01 UTC.

RevendicationSignification
issÉmetteur : qui a créé et signé le jeton
subSujet : l’utilisateur ou l’entité concernée par le jeton
audAudience : le destinataire prévu du jeton
expDate d’expiration : rejeter le jeton après cet instant
nbfPas avant : rejeter le jeton avant cet instant
iatÉmis le : date de création du jeton
jtiID du JWT : identifiant unique, utilisé contre le rejeu

Valeurs courantes de alg

Valeur de algSignification
HS256HMAC avec SHA-256 ; un secret partagé signe et vérifie
RS256Signature RSA PKCS#1 v1.5 avec SHA-256 ; la clé privée signe, la clé publique vérifie
PS256RSA-PSS avec SHA-256
ES256ECDSA sur la courbe P-256 avec SHA-256 ; signatures courtes
EdDSASignatures Ed25519 ou Ed448
noneJeton non signé ; les serveurs doivent le rejeter

Ce que contient un JSON Web Token

Le JWT est défini par la RFC 7519 (mai 2015), qui suggère de le prononcer comme le mot anglais « jot ». La forme signée courante est composée de trois chaînes Base64url reliées par des points : header.payload.signature. L'en-tête (header) indique l'algorithme de signature dans alg, comme HS256 ou RS256, et souvent un identifiant de clé dans kid. Le payload contient des claims, des champs JSON tels que sub (l'utilisateur), iss (l'émetteur), aud (le destinataire prévu) et exp, nbf et iat, qui sont des dates exprimées en secondes depuis le 1er janvier 1970 UTC. Le décodeur convertit ces trois valeurs dans votre heure locale et en ISO 8601, et vous indique si le jeton a expiré, n'est pas encore valide ou se trouve dans sa période de validité.

Base64url est un encodage, pas un chiffrement : toute personne qui détient un jeton peut lire son payload, exactement comme le fait cette page. Ne placez jamais de mots de passe, de numéros de carte ou d'autres secrets dans les claims. Un jeton à cinq parties séparées par des points est un JWE, un jeton chiffré ; son contenu est illisible sans la clé, et le décodeur vous le signale. Un « Bearer » placé au début et copié depuis un en-tête Authorization est supprimé automatiquement.

Pourquoi la signature n’est pas vérifiée ici

La signature prouve que l'en-tête et le payload ont été produits par une personne détenant la clé et qu'ils n'ont pas été modifiés depuis. Pour la vérifier, il faut cette clé : le secret partagé pour les algorithmes HMAC comme HS256, ou la clé publique de l'émetteur pour RS256, ES256 ou EdDSA. Coller un secret de signature de production dans une page web est une mauvaise idée, et un décodeur qui prétendrait garantir un jeton sans clé donnerait une fausse impression de sécurité : cet outil affiche donc la signature sans la vérifier. Considérez ce que vous voyez comme une déclaration du jeton, pas comme un fait établi.

La vérification doit se faire sur votre serveur, avec une bibliothèque maintenue et l'algorithme attendu imposé. Deux erreurs historiques l'expliquent : accepter alg « none », ce qui permet à n'importe qui de forger un jeton non signé, et la confusion d'algorithme, où un serveur qui attend du RS256 est amené à vérifier une signature HS256 en utilisant la clé publique comme secret HMAC. Un décodeur sert au débogage : voir quels claims un fournisseur émet, repérer une audience incorrecte, ou comprendre qu'une session a échoué parce que exp est dépassé depuis une minute. Pour lire les segments Base64url bruts, utilisez le décodeur Base64.

Questions fréquentes

Peut-on coller sans risque un vrai jeton d’accès dans un décodeur JWT ?
Sur cette page, le jeton ne quitte jamais votre navigateur. Cependant, un jeton valide fonctionne comme un mot de passe jusqu'à son expiration : privilégiez des jetons expirés ou de test, et gardez les jetons actifs hors des captures d'écran et des conversations.
Pourquoi mon jeton apparaît-il expiré alors qu’il vient d’être émis ?
Vérifiez d'abord l'horloge de votre appareil. Certains émetteurs donnent aux jetons d'accès une durée de vie de quelques minutes seulement, et un jeton copié depuis un journal peut être plus ancien qu'il n'y paraît. Un exp écrit en millisecondes au lieu de secondes produit l'effet inverse et tombe des milliers d'années dans le futur.
Quelqu’un peut-il modifier le payload de mon JWT ?
Elle peut le modifier et le réencoder, mais la signature ne correspondra plus. Un serveur qui vérifie les signatures avec la bonne clé et le bon algorithme rejette le jeton altéré.
Quelle est la différence entre JWS et JWE ?
Un JWS (RFC 7515) est signé, comporte trois parties et peut être lu par tout le monde. Un JWE (RFC 7516) est chiffré, comporte cinq parties et seul le détenteur de la clé peut lire le payload.
La déconnexion invalide-t-elle un JWT ?
Pas à lui seul. Un JWT signé reste valide jusqu'à exp, sauf si le serveur tient une liste de refus ou consulte un enregistrement de session, ce qui explique pourquoi les jetons d'accès ont généralement une durée de vie courte.