Décodeur JWT

S’exécute dans votre navigateur ; rien n’est envoyé

Lisez l’en-tête et les claims d’un JSON Web Token, voyez quand il expire et vérifiez sa signature avec votre secret ou votre clé publique.

Token

Verify signature

Paste a token to check its signature against a secret or public key.

No token yet

The header and payload appear here as JSON, and Claims lists each claim with what it means and when it expires.
Ready

Qu’est-ce qu’un JWT ?

Un JSON Web Token (JWT) est un moyen compact et signé de transmettre des claims entre deux parties, le plus souvent d’un serveur d’authentification à une API. Il se compose de trois chaînes Base64url reliées par des points, header.payload.signature, et les API l’attendent généralement dans l’en-tête Authorization: Bearer <token>.

L’en-tête indique comment le jeton est signé, par exemple "alg": "HS256" pour un HMAC avec un secret partagé ou RS256 pour une paire de clés RSA. Le payload contient les claims : des claims standard comme sub (le sujet du jeton), iat (sa date d’émission) et exp (sa date d’expiration), plus tout ce qu’ajoute l’émetteur, comme des rôles ou des scopes.

C’est la signature qui rend un jeton fiable. L’émetteur la calcule sur l’en-tête et le payload avec sa clé : modifier un seul caractère du payload la casse. Le payload est encodé, pas chiffré : toute personne qui possède le jeton peut lire tous les claims. N’y mettez donc jamais de secrets, et traitez le jeton lui-même comme un mot de passe jusqu’à son expiration.

Comment utiliser cet outil

  1. 1Collez un jeton dans le panneau Token, ou choisissez-en un dans Examples. Le préfixe Bearer, le nom d’en-tête Authorization:, les guillemets et les retours à la ligne sont ignorés, et l’en-tête du panneau indique ce qui l’a été.
  2. 2L’en-tête, le payload et la signature sont colorés dans le jeton. Payload et Header affichent chaque partie en JSON ; Claims liste chaque claim avec sa signification et affiche iat, nbf et exp sous forme de dates dans votre fuseau horaire, avec le temps écoulé ou restant.
  3. 3La barre d’état affiche l’algorithme, quand le jeton expire ou a expiré, et si la signature a été vérifiée. Les avertissements, comme alg: none ou l’absence d’exp, apparaissent en haut de Claims.
  4. 4Pour vérifier la signature, saisissez le secret partagé (HS256, HS384, HS512 ; passez en Base64 si le secret est encodé) ou collez la clé publique de l’émetteur (RS*, PS*, ES*, EdDSA) au format PEM, certificat X.509, JWK ou ensemble de JWK. Le résultat s’affiche pendant la saisie.
  5. 5Si le jeton ne peut pas être décodé, le message indique quelle partie et quel caractère posent problème ; appuyez sur F8 pour le sélectionner.

Dépannage

Ce jeton a 5 parties : c’est un JWE chiffré
Certains fournisseurs d’identité émettent des jetons chiffrés (JWE). Leur payload ne peut être lu qu’avec la clé privée du destinataire : aucun décodeur ne peut l’afficher sans cette clé.
+ relève du Base64 standard ; les JWT utilisent le Base64url
Le jeton a été réencodé ou construit à la main avec du Base64 standard. Les parties d’un JWT utilisent - et _ au lieu de + et /, sans remplissage =.
La signature ne correspond pas à ce secret
Vérifiez que le secret est exactement celui de l’émetteur, casse et espaces finaux compris, et s’il est stocké en Base64 ; dans ce cas, passez le format du secret en Base64.
C’est une clé RSA PKCS#1 (BEGIN RSA PUBLIC KEY)
Les navigateurs n’importent que les clés au format SubjectPublicKeyInfo. Convertissez-la avec openssl rsa -RSAPublicKey_in -in key.pem -pubout, ou collez plutôt le JWK de l’endpoint JWKS de l’émetteur.
L’ensemble de clés ne contient aucune clé avec ce kid
Les émetteurs font tourner leurs clés. Récupérez l’ensemble de JWK actuel depuis le jwks_uri de l’émetteur et collez-le à nouveau ; l’outil choisit la clé dont le kid correspond à l’en-tête du jeton.

Questions fréquentes

Puis-je coller ici un vrai jeton ou un vrai secret sans risque ?

Le décodage et la vérification de signature se font dans votre navigateur avec Web Crypto, et rien n’est envoyé nulle part. Le jeton est conservé dans le session storage de cet onglet jusqu’à ce que vous l’effaciez ou fermiez l’onglet, donc un rechargement ne le fait pas disparaître ; le secret ou la clé utilisés pour la vérification ne sont jamais enregistrés, et les jetons ne sont jamais mis dans des liens. Malgré tout, un jeton valide donne accès jusqu’à son expiration : préférez des jetons de test ou expirés, et ne collez jamais de secrets de signature de production dans un site que vous ne contrôlez pas.

Que signifie "Signature verified" ?

Que l’en-tête et le payload ont été signés avec le secret, ou avec la clé privée qui correspond à la clé publique fournie. Cela ne dit pas que le jeton est acceptable : votre API doit aussi vérifier exp, nbf, l’émetteur (iss) et l’audience (aud), et décider quels algorithmes elle accepte.

Pourquoi alg none est-il dangereux ?

Un jeton avec "alg": "none" n’a pas de signature : n’importe qui peut en écrire un avec les claims de son choix. Les bibliothèques qui l’acceptent par erreur permettent aux attaquants de forger des jetons. Les serveurs doivent refuser les jetons non signés.

Dans quel format sont iat, nbf et exp ?

En secondes depuis le 1er janvier 1970 UTC (temps Unix). Une valeur à 13 chiffres est en millisecondes, un bug courant chez les émetteurs de jetons ; l’outil le signale. Le convertisseur de timestamp Unix transforme n’importe laquelle de ces valeurs en date.

Pourquoi mon jeton est-il refusé alors qu’il se décode bien ?

Les causes courantes sont une signature faite avec une autre clé, un aud ou un iss incorrect, un jeton utilisé avant son nbf ou après son exp, ou des horloges décalées entre serveurs. Lisez la réponse d’erreur de l’API et comparez ces claims.