Décodeur JWT

Qu’est-ce qu’un JWT ?#

Un JWT (JSON Web Token, défini dans la RFC 7519) est un jeton compact et sûr pour les URL, bâti pour transporter des claims entre deux parties. C’est le justificatif que votre navigateur envoie à une API après connexion, l’assertion d’identité qu’un fournisseur OAuth remet à une application utilisatrice, et l’enveloppe dans laquelle voyagent la plupart des flux modernes de session et de contrôle d’accès. Son attrait : les claims — qui est l’utilisateur, ce qu’il peut faire, quand le jeton expire — voyagent à l’intérieur du jeton lui-même en JSON, si bien que le service récepteur peut les lire sans consultation de base.

Un JWT compte exactement trois parties encodées en base64url séparées par des points : header.payload.signature. L’en-tête nomme l’algorithme et le type de jeton. La charge utile est un objet JSON de claims — les claims enregistrés comme sub (sujet), iat (émis à), exp (expiration), nbf (pas avant), plus toute claim personnalisée que votre application ajoute. La signature est ce que l’émetteur a calculé sur les deux autres parties avec un secret ou une clé privée ; la vérifier prouve que le jeton n’a pas été altéré.

Cette page décode et inspecte un JWT. Elle sépare les trois parties, décode en base64url l’en-tête et la charge utile en JSON lisible, fait émerger les claims temporels standards sous forme d’horodatages lisibles, et affiche un badge d’état en direct (Valid, Expired, Not yet valid). Elle ne vérifie délibérément pas la signature — cela exige le secret ou la clé publique de l’émetteur et sort du cadre d’un outil 100 % côté client. Le segment de signature est affiché brut, exactement tel que reçu.

Comment l’utiliser#

1. Collez votre jeton dans le champ Entrée à gauche. Il doit comporter trois segments séparés par des points ; les blancs autour sont retirés automatiquement.
2. Cliquez sur Exemple pour charger un jeton d’exemple intégré (avec iat/exp/nbf) si vous voulez simplement voir la disposition.
3. Cliquez sur Effacer pour vider l’entrée et les panneaux de résultat.
4. Lisez le panneau de droite :
   • Le badge d’état en haut — Valid vert, Expired ou Not yet valid — fondé sur les claims nbf et exp comparés à l’heure courante.
   • La carte Header (avec l’algorithme affiché dans sa barre de titre, par ex. HS256).
   • La carte Payload, joliment imprimée en JSON.
   • La liste des claims temporels — Issued at, Not before, Expires — chacun rendu à la fois comme horodatage Unix et comme date lisible.
   • Le segment Signature, affiché brut parce qu’il reste en octets encodés base64url.
5. Si le jeton est mal formé, la ligne d’état rouge vous dit s’il a échoué au contrôle de forme des trois segments, au décodage base64url ou à l’analyse JSON.

Fonctionnalités clés#

• État des claims temporels en direct. Lit iat, nbf et exp et vous dit si le jeton est actuellement valide, déjà expiré ou pas encore en vigueur — les trois questions que vous posez vraiment pendant un bogue de connexion.
• Dates lisibles. Les nombres d’epoch Unix comme 1700000000 sont affichés à côté de la date UTC qu’ils représentent, pour que vous arrêtiez l’arithmétique mentale d’epoch.
• Algorithme mis en évidence. La valeur alg de l’en-tête est tirée dans la barre de titre de la carte Header, pour que vous voyiez immédiatement si vous tenez un HS256, un RS256 ou quelque chose d’inattendu.
• Décodage sûr en UTF-8. Les segments base64url sont décodés en octets via TextDecoder, donc les claims non ASCII (noms, rôles dans d’autres écritures) s’affichent correctement au lieu de mojibake.
• Décoder seulement — jamais vérifier. L’outil ne demande jamais de secret, ce qui le rend sûr pour coller des jetons à qui vous ne faites pas entièrement confiance : rien n’est envoyé nulle part, et la signature est affichée mais non vérifiée.

Exemple commenté#

Cliquez sur Exemple et l’entrée se remplit avec un jeton dont l’en-tête se décode en :

{
  "alg": "HS256",
  "typ": "JWT"
}

et dont la charge utile se décode en :

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

La liste des claims temporels affiche alors :

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

Le badge d’état indique Valid, parce que l’heure courante se situe après nbf et avant exp. Le segment de signature est affiché comme la chaîne littérale c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ — qui se décode en le texte « sample-signature-not-verified », un marqueur délibéré que la signature de ce jeton est illustrative et non une véritable sortie HMAC-SHA256.

Ce dernier point est la chose la plus importante à comprendre de cet outil : un jeton qui se décode proprement n’est pas nécessairement un jeton digne de confiance. N’importe qui peut forger l’en-tête et la charge utile ; seule la signature, vérifiée contre le secret ou la clé publique de l’émetteur, prouve l’authenticité. Utilisez cette page pour lire les claims et déboguer les fenêtres temporelles ; vérifiez les signatures dans votre véritable backend.

FAQ#

Cet outil peut-il me dire si un JWT est authentique ?#

Non, et c’est délibéré. Décoder se contente de lire le JSON à l’intérieur du jeton — il ne prouve pas que le jeton a été émis par qui prétend l’avoir émis. Pour vérifier l’authenticité, il vous faut la clé appropriée au alg (un secret partagé pour HS256, la clé publique de l’émetteur pour RS256/ES256) et une routine de vérification sur un backend de confiance. Ne traitez jamais un jeton proprement décodé comme un jeton vérifié.

L’état indique « Expired ». Puis-je rafraîchir le jeton ici ?#

Non. Rafraîchir signifie appeler l’endpoint de rafraîchissement de votre serveur d’authentification pour obtenir un nouveau jeton d’accès — une opération réseau que cette page statique côté client ne peut pas et ne doit pas effectuer. Ce que vous pouvez faire ici, c’est confirmer exactement quand l’ancien jeton a expiré — c’est généralement l’indice dont vous aviez besoin.

Quelle est la différence entre iat, nbf et exp ?#

iat (issued at) est le moment où le jeton a été créé — informatif. nbf (not before) est le moment le plus tôt où le jeton devrait être accepté ; avant nbf, un serveur validant devrait le rejeter même si la signature est valide. exp (expiration) est la coupure stricte au-delà de laquelle le jeton doit être rejeté. Un jeton bien formé a nbf ≤ iat ≈ maintenant et exp quelque part dans un futur proche (minutes pour les jetons d’accès, plus long pour les jetons de rafraîchissement).

Ma charge utile contient des caractères non ASCII et ils apparaissent garillonnés ailleurs. Pourquoi sont-ils corrects ici ?#

Parce que certains décodeurs traitent par erreur chaque caractère base64url comme un octet au lieu de décoder d’abord en octets bruts. Cette page décode en Uint8Array puis le passe dans TextDecoder, qui interprète les octets comme du véritable UTF-8. C’est la bonne façon, et c’est pourquoi noms, rôles et scopes dans toute écriture s’affichent tels qu’ils ont été écrits.