Décodeur de jetons JWT
Décodez n'importe quel jeton Web JSON pour lire son en-tête, sa charge utile et son expiration en langage clair, sans envoyer le jeton nulle part.
JWT
Le décodage se fait dans votre navigateur. Le jeton n'est jamais envoyé nulle part.
Décodé
En-tête
Charge utile
Signature
Vérifier la signature exige le secret ou la clé publique, qui ne font pas partie du jeton.
Comment utiliser le décodeur JWT
Collez un JSON Web Token complet : trois segments Base64Url séparés par des points. Le décodeur sépare le jeton, décode chaque partie et affiche l'en-tête et la charge utile en JSON formaté. Les revendications standards comme exp, iat, nbf, iss, aud et sub sont expliquées en langage clair, y compris si le jeton est expiré. Vous pouvez coller une valeur « Authorization: Bearer » complète, et le préfixe sera retiré.
Pourquoi décoder les jetons localement
Les JWT sont partout dans l'authentification moderne : OAuth 2.0, OpenID Connect, accès aux API, liens magiques et liens de réinitialisation de mot de passe. Déboguer un appel d'API qui échoue commence habituellement par la lecture des revendications du jeton. Bien des décodeurs en ligne envoient votre jeton à un serveur, une mauvaise habitude pour des jetons qui peuvent encore être valides. Ce décodeur fonctionne entièrement dans votre navigateur.
Usages courants
- Déboguer les réponses « 401 Unauthorized » en vérifiant les revendications
- Confirmer qu'un jeton n'est pas expiré
- Vérifier que l'audience (aud) correspond à ce qu'attend votre API
- Voir quels rôles ou quelles portées contient le jeton d'un utilisateur
- Montrer aux nouveaux ingénieurs comment un JWT est construit
Structure d'un JWT : header.payload.signature
L'en-tête indique l'algorithme de signature (alg) et le type de jeton (typ). La charge utile contient les revendications : des standards comme exp, iat et iss, plus des revendications personnalisées comme les rôles ou les permissions. La signature prouve que le jeton n'a pas été modifié. Décoder n'est pas vérifier : n'importe qui peut lire n'importe quel JWT, mais seule une personne qui détient la bonne clé peut confirmer la signature.
Pourquoi les signatures ne peuvent pas être vérifiées ici
La vérification exige soit le secret partagé (pour les algorithmes HMAC comme HS256), soit la clé publique de l'émetteur (pour les algorithmes RSA ou ECDSA comme RS256). Ni l'un ni l'autre ne se trouve dans le jeton. Le jeton seul vous dit ce que l'émetteur affirme. Seule la clé vous confirme qu'il vient vraiment de l'émetteur.
Questions fréquentes
Est-ce sécuritaire de coller mon JWT ici?
Le décodeur fonctionne dans votre navigateur et n'envoie rien à aucun serveur. Malgré tout, traitez tout jeton non expiré qui donne accès à quelque chose d'important comme un mot de passe, et méfiez-vous des outils qui pourraient l'enregistrer.
Les JWT sont-ils chiffrés?
Les JWT standards sont signés, pas chiffrés, donc n'importe qui peut lire la charge utile. Les jetons chiffrés utilisent JWE (JSON Web Encryption), une norme distincte en cinq parties au lieu de trois. Ne mettez pas de secrets dans la charge utile d'un JWT ordinaire.
Que signifie « JWT signature invalid » dans mes journaux d'API?
Le jeton a été modifié, a été signé avec une autre clé, ou votre vérificateur attend un autre algorithme. Décodez l'en-tête et confirmez que la valeur alg correspond à la configuration de votre vérificateur.
Où les revendications standards sont-elles définies?
La RFC 7519 définit iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis à) et jti (identifiant du JWT). Les revendications personnalisées sont libres. Parmi les plus courantes : roles, scope, email et tenant_id.