Décodeur et encodeur JWT
Les échecs d'authentification JWT sont opaques. Une réponse 401 ne vous dit rien : vous ne pouvez pas voir si le jeton a expiré, si la revendication d'audience est erronée, quel algorithme a été utilisé ou si la charge utile a été falsifiée. La plupart des outils en ligne ne font que décoder : ils ne peuvent pas encoder un nouveau jeton, vérifier une signature ou générer des clés – et beaucoup envoient vos jetons à des serveurs externes.
Cet outil gère les quatre opérations JWT en un seul endroit, décoder, encoder, vérifier et générer des clés, avec une prise en charge complète des algorithmes HMAC (HS256, HS384, HS512), RSA et RSA-PSS. Inspectez les revendications de n'importe quel jeton sans clé de signature, codez de nouveaux jetons avec des charges utiles personnalisées, vérifiez les signatures par rapport aux secrets ou aux clés publiques et générez des clés aléatoires cryptographiquement sécurisées prêtes pour la production. Tout s'exécute dans votre navigateur via l'API Web Crypto : aucun jeton, clé ou charge utile ne quitte votre appareil.
Décoder JWT
Encoder JWT
Vérifier la signature JWT
Générateur de clé secrète JWT
Qu'est-ce qu'un décodeur JWT ?
Un décodeur JWT – également appelé analyseur, débogueur ou visualiseur JWT – est un outil qui divise un jeton Web JSON en trois parties : en-tête, charge utile et signature, affichant chacune sous forme de JSON lisible. Un encodeur JWT fait l'inverse : il prend un en-tête, une charge utile et une clé de signature, et produit un jeton compact signé. JSON Web Token (JWT, prononcé « jot ») est un standard ouvert défini par l'IETF dans la RFC 7519 pour transmettre des revendications vérifiées entre deux parties sous la forme d'une chaîne compacte et sécurisée pour les URL.
Les JWT constituent le fondement de l'authentification sans état dans l'architecture Web moderne. Une fois qu'un utilisateur s'est connecté, le serveur d'autorisation émet un JWT signé contenant des revendications vérifiées (un ID utilisateur, un rôle, une heure d'expiration) et le renvoie au client. Le client attache ce jeton à chaque requête API ultérieure. Le serveur vérifie la signature numérique sans consulter un magasin de sessions, ce qui rend le système rapide et évolutif à travers les microservices. Dans la plupart des systèmes, un jeton d'accès de courte durée et un jeton d'actualisation de plus longue durée sont émis ensemble : le jeton d'accès porte les revendications JWT, tandis que le jeton d'actualisation est utilisé pour en demander un nouveau après expiration.
Les deux protocoles les plus courants qui dépendent des JWT sont OAuth 2.0 (autorisation) et OpenID Connect (OIDC, identité et authentification). Dans les deux cas, les JWT portent des revendications standardisées définies dans la RFC 7519. Google, Microsoft, Okta et Auth0 émettent tous des jetons d'identification OIDC en tant que JWT.
Contrairement au package jwt-decode npm – qui décode uniquement les jetons – cet outil encode et décode également les jetons avec n'importe quel algorithme HMAC ou RSA, vérifie les signatures et génère des clés secrètes, le tout sans quitter votre navigateur. Les principales bibliothèques JWT dans d'autres langages incluent PyJWT (Python), jjwt (Java), golang-jwt (Go) et jose (Rust), utilisez cet outil pour tester les jetons générés par l'un d'entre eux.
Comment utiliser cet outil
Décoder un JWT
- Collez le JWT encodé que vous souhaitez inspecter dans le champ Décoder JWT.
- Cliquez sur Décoder JWT.
- L'en-tête et la charge utile apparaissent au format JSON : vous pouvez voir chaque réclamation que l'émetteur a choisi d'encoder dans le jeton. Vérifiez les réclamations, l'algorithme, l'horodatage d'expiration, l'émetteur et tous les champs personnalisés, aucune clé de signature n'est requise.
Encoder un JWT
- Sélectionnez un algorithme de signature dans la liste déroulante : HS256 pour encoder avec HMAC, RS256 ou PS256 pour encoder avec RSA.
- Saisissez votre clé secrète (HMAC) ou clé privée au format PEM (RSA / RSA-PSS).
- Modifiez l'en-tête JSON pour définir alg et typ.
- Modifiez le Payload JSON avec vos revendications : sub, iat, exp, rôles ou tout autre champ personnalisé.
- Cliquez sur Encoder JWT pour encoder et signer votre jeton en une seule étape.
Vérifier une signature JWT
- Collez le jeton dans le champ Vérifier JWT.
- Saisissez la clé secrète (HMAC) ou la clé publique au format PEM (RSA / RSA-PSS). L'algorithme est lu automatiquement à partir de l'en-tête du jeton.
- Cliquez sur Vérifier JWT. L'outil réexécute le même processus que celui utilisé pour coder la signature et compare le résultat. Valide = correspondances de signature. Invalide = mauvaise clé ou charge utile falsifiée.
Générer une clé secrète
- Sélectionnez la longueur de la clé : 256 bits pour HS256, 384 bits pour HS384, 512 bits pour HS512.
- Cliquez sur Générer un secret.
- Copiez et stockez la clé dans une variable d'environnement ou un gestionnaire de secrets. Ne mettez jamais de secrets de signature dans le code source. Pour des formats secrets supplémentaires, consultez notre générateur de mots de passe.
Comment lire vos résultats
En-tête décodé
L'en-tête décodé révèle les paramètres choisis lors de l'encodage du JWT. Il s'agit d'un objet JSON avec deux champs standards : alg (l'algorithme de signature, "HS256", "RS256", "PS256", etc.) et typ (toujours "JWT"). Si un champ kid (Key ID) est présent, il identifie quelle clé a été utilisée pour signer le jeton – utilisé lorsqu'un serveur d'autorisation publie plusieurs clés publiques via un point de terminaison JWKS (JSON Web Key Set) et les fait pivoter au fil du temps.
Charge utile décodée
La charge utile contient les revendications du jeton – des données sur le sujet authentifié. Les revendications enregistrées standard incluent sub (sujet – généralement un identifiant utilisateur), iss (émetteur), aud (audience), exp (expiration – un horodatage Unix), iat (émis à), nbf (pas avant) et jti (ID JWT). Les revendications personnalisées ajoutées par votre application (rôles, ID d'organisation, étendues d'autorisation, niveau d'abonnement) apparaissent également ici.
La charge utile est codée en Base64URL et non chiffrée. Toute personne possédant le jeton peut décoder et lire la charge utile. Ne stockez jamais de mots de passe, d'informations de paiement, d'identifiants nationaux ou de données personnelles sensibles dans une charge utile JWT. Pour les jetons qui doivent transporter des données sensibles, utilisez plutôt JWE (RFC 7516).
Résultat de la vérification de la signature
La vérification recalcule la signature créée lors du codage du jeton, à l'aide de l'en-tête, de la charge utile et de la clé que vous fournissez, puis la compare octet par octet à la signature codée dans le jeton. Valid confirme que le jeton a été signé par le détenteur de cette clé et que rien n'a été modifié. Invalide signifie que la clé est erronée ou que le jeton a été falsifié après la signature. Le décodage à lui seul ne prouve jamais l’authenticité – vérifiez toujours avant de donner suite à toute réclamation en production.
Structure des jetons JWT
Un JWT est constitué de trois chaînes codées en Base64URL reliées par des points : [header].[payload].[signature]. Lorsque vous encodez un JWT, chaque section est codée en Base64URL et jointe par des points. Lorsque vous le décodez, chaque section est séparée et affichée au format JSON. L'en-tête identifie l'algorithme. La charge utile porte les réclamations. La signature prouve qu'aucun des deux n'a été modifié.
[header].[payload].[signature]Voici un exemple de jeton JWT montrant comment les trois parties sont divisées :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← en-tête
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ ← charge utile
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← signatureCollez cet exemple de JWT dans le décodeur ci-dessus pour voir chaque partie décodée.
En-tête
L'en-tête est un objet JSON que vous encodez dans le JWT en tant que Base64URL. Il spécifie le type de jeton (« JWT ») et l'algorithme utilisé pour créer la signature, par exemple « HS256 » (HMAC-SHA256) ou « RS256 » (RSASSA-PKCS1-v1_5). Certains jetons incluent un enfant (Key ID) pour indiquer au destinataire quelle clé publique utiliser pour la vérification lorsque l'émetteur effectue une rotation des clés.
Charge utile
La charge utile est un objet JSON contenant les revendications – codées en Base64URL mais non chiffrées. La RFC 7519 définit trois catégories de revendications : les revendications enregistrées (noms standardisés comme sub, iss, exp), les revendications publiques (enregistrées dans le registre IANA JSON Web Token Claims pour éviter les collisions) et les revendications privées (champs personnalisés spécifiques à l'application convenus entre l'émetteur et le consommateur).
Signature
La signature est la signature numérique qui rend les JWT résistants aux modifications : elle lie l’en-tête et la charge utile et prouve qu’ils proviennent d’une source fiable. Pour les algorithmes HMAC, il s’agit de HMACSHA256(base64url(header) + "." + base64url(payload), secret). Pour RSA, une clé privée signe et tout détenteur de la clé publique correspondante vérifie. Modifiez un seul octet dans l’en-tête ou la charge utile après signature et la signature devient invalide, ce qui constitue la garantie de sécurité centrale de JWS (RFC 7515).
Réclamations JWT courantes
Les revendications enregistrées JWT sont des noms de champs standardisés définis dans la RFC 7519. Les plus importants sont exp (délai d'expiration), sub (sujet – généralement un identifiant utilisateur), iss (émetteur) et aud (audience). Tous sont facultatifs mais largement implémentés dans les systèmes OAuth 2.0 et OIDC.
Noms de revendications enregistrés RFC 7519, facultatifs mais largement pris en charge dans les systèmes OAuth 2.0 et OIDC :
Réclamation | Nom complet | Tapez | Exemple de valeur | Descriptif |
|---|---|---|---|---|
| iss | Émetteur | Chaîne/URI | "https://auth.example.com" | Le serveur ou l'application qui a émis le jeton |
| sub | Sujet | Chaîne | "user_abc123" | À qui s'adresse le jeton ? généralement un identifiant utilisateur |
| aud | Public | Chaîne/Tableau | "api.example.com" | Quel(s) service(s) doivent accepter ce jeton |
| exp | Délai d'expiration | Date numérique | 1716239022 | Horodatage Unix, le jeton n'est plus valide après ce point |
| nbf | Pas avant | Date numérique | 1716235422 | Le jeton ne doit pas être accepté avant cet horodatage |
| iat | Publié à | Date numérique | 1716235422 | Quand le jeton a été créé |
| jti | ID JWT | Chaîne | "a1b2c3d4e5" | Identifiant unique ; utilisé pour empêcher les attaques par rejeu |
| kid | ID de clé | Chaîne | "2025-key-01" | Identifie quelle clé a signé le jeton lorsque plusieurs clés sont utilisées |
Les valeurs NumericDate (exp, nbf, iat) correspondent aux secondes écoulées depuis l'époque Unix, 00:00:00 UTC le 1er janvier 1970.
Lorsque vous encodez un JWT, ajoutez des revendications privées pour les données spécifiques à l'application : rôles, niveau d'abonnement, ID d'organisation, étendues d'autorisation. Utilisez un nom de style URI tel que « https://yourapp.com/role » pour éviter de futures collisions de registre IANA.
Algorithmes de signature pris en charge
Cet outil prend en charge les trois variantes HMAC (HS256, HS384, HS512) et les six variantes RSA/RSA-PSS (RS256, RS384, RS512, PS256, PS384, PS512), telles que définies dans la RFC 7518 (algorithmes Web JSON). Choisissez HMAC pour les configurations à service unique ; choisissez RSA pour les systèmes distribués où les services vérifient les jetons sans partager la clé de signature.
Algorithme | Famille | Type de clé | Rembourrage | Utilisation recommandée |
|---|---|---|---|---|
| HS256 | HMAC | Secret partagé | — | Par défaut pour l'authentification à service unique |
| HS384 | HMAC | Secret partagé | — | Un hachage plus fort pour les exigences de conformité |
| HS512 | HMAC | Secret partagé | — | Résistance maximale du HMAC |
| RS256 | RSA | Paire de clés | PKCS#1 v1.5 | Largement pris en charge ; utilisation dans les systèmes distribués |
| RS384 | RSA | Paire de clés | PKCS#1 v1.5 | Hachage plus long pour la famille RS |
| RS512 | RSA | Paire de clés | PKCS#1 v1.5 | Résistance RS maximale |
| PS256 | RSA-PSS | Paire de clés | PSS (probabilistic) | Préféré au RS256 pour les nouvelles implémentations |
| PS384 | RSA-PSS | Paire de clés | PSS (probabilistic) | — |
| PS512 | RSA-PSS | Paire de clés | PSS (probabilistic) | — |
HMAC (symétrique), HS256, HS384, HS512
Les algorithmes HMAC (définis dans la RFC 2104) utilisent un secret partagé pour la signature et la vérification. L'émetteur du jeton et chaque service qui vérifie les jetons doivent détenir le même secret.
- HS256: HMAC avec SHA-256. L'algorithme de signature JWT le plus courant dans l'écosystème. Longueur minimale recommandée du secret : 256 bits (32 octets).
- HS384: HMAC avec SHA-384. À utiliser lorsque votre politique de sécurité nécessite une taille de hachage plus grande.
- HS512: HMAC avec SHA-512. Résistance HMAC maximale pour les environnements hautement conformes.
RSA et RSA-PSS (asymétrique), RS256, RS384, RS512, PS256, PS384, PS512
Les algorithmes RSA utilisent une paire de clés. Les signes de clé privée ; la clé publique vérifie. Les services de vérification n'ont besoin que de la clé publique, qui peut être publiée ouvertement via un point de terminaison JWKS.
- RS256 / RS384 / RS512: Rembourrage RSASSA-PKCS1-v1_5. Largement pris en charge sur toutes les bibliothèques et plates-formes JWT.
- PS256 / PS384 / PS512: Rembourrage RSASSA-PSS. Schéma de signature probabiliste avec des propriétés de sécurité plus fortes que PKCS#1 v1.5. Recommandé par rapport aux variantes RS pour les nouvelles implémentations (voir RFC 8017).
Taille minimale de la clé RSA : 2 048 bits ; préférez 4096 bits pour les clés de signature de longue durée. Utilisez HMAC lorsqu'un service émet et vérifie des jetons. Utilisez RSA ou RSA-PSS lorsque des services indépendants doivent vérifier les jetons sans partager le secret de signature.
Vulnérabilités de sécurité JWT
JWT est sécurisé lorsqu'il est correctement implémenté. Trois vulnérabilités apparaissent systématiquement dans les audits de sécurité des API : le contournement alg:none, la confusion des algorithmes et les secrets HMAC faibles. Tous proviennent d'erreurs de mise en œuvre, et non de défauts de la RFC 7519. La RFC 8725 (JWT Best Current Practices, IETF) fournit les conseils d'atténuation faisant autorité.
L'attaque alg:none
Un attaquant modifie l'en-tête du jeton pour définir "alg": "none", puis supprime le segment de signature. Si le serveur accepte le champ alg de l'en-tête du jeton sans validation, il ignore entièrement la vérification de la signature et fait confiance au jeton non signé.
Mettez toujours sur liste blanche les algorithmes acceptés côté serveur. Ne laissez jamais l’en-tête du jeton déterminer l’algorithme à utiliser pour encoder ou vérifier ; déduisez-le de votre propre configuration. Chaque grande bibliothèque JWT possède un paramètre algorithms explicite : transmettez-le. Exemple : jwt.verify(token, secret, {'{'} algorithms: ['HS256'] {'}'})
Confusion d'algorithmes (RS256 à HS256)
Si un serveur utilise une clé publique RSA pour vérifier les jetons mais n'applique pas alg, un attaquant peut remplacer l'en-tête par « alg » : « HS256 » et signer le jeton en utilisant la clé publique comme secret HMAC. Le serveur traite ensuite la clé publique comme un secret HMAC partagé et accepte le jeton falsifié.
Appliquez l’algorithme attendu côté serveur. N'utilisez jamais le même matériel de clé pour plusieurs familles d'algorithmes. Configurez explicitement votre bibliothèque pour accepter uniquement RS256 ou PS256 lors de l'utilisation de clés RSA.
Faibles secrets du HMAC
Les jetons HS256 signés avec des secrets courts ou devinables peuvent être forcés hors ligne. Un attaquant qui intercepte un jeton valide peut exécuter des attaques par dictionnaire ou par table arc-en-ciel contre la signature sans aucune interaction du serveur. Les secrets faibles courants incluent le « secret », le « mot de passe » ou les noms d'application.
Utilisez le générateur de secrets intégré sur cette page pour produire une clé cryptographiquement aléatoire de 256 bits (ou plus). Faites pivoter le secret immédiatement en cas d'exposition suspectée.
Validation de réclamation manquante
Une signature valide prouve que le jeton a été émis par une partie connue ; elle ne prouve pas que le jeton est approprié pour la demande en cours. Ne pas valider exp (expiration), aud (audience) ou iss (émetteur) permet aux attaquants de rejouer les jetons expirés, d'utiliser des jetons émis pour un service différent ou d'utiliser des jetons provenant d'un émetteur non fiable.
Validez toujours exp pour rejeter les jetons expirés. Validez aud pour vous assurer que le jeton a été émis pour votre service spécifique. Validez iss pour rejeter les jetons provenant d’émetteurs inattendus. La plupart des bibliothèques JWT gèrent ces vérifications automatiquement si vous transmettez les valeurs attendues dans les options de vérification.
JWT et authentification basée sur la session
Les JWT sont sans état : toutes les données de session sont codées dans le jeton. L'authentification basée sur la session stocke les données de session côté serveur et donne au client uniquement un ID de session. Les JWT s'adaptent mieux horizontalement ; les sessions prennent en charge la révocation instantanée.
Caractéristique | JWT (apatride) | Basé sur la session (avec état) |
|---|---|---|
| Où l'état est stocké | À l'intérieur du jeton (côté client) | Côté serveur (base de données ou cache) |
| Évolutivité | Horizontal – pas de magasin de sessions partagées | Nécessite un stockage de sessions partagé dans les configurations multi-serveurs |
| Révocation | Impossible de révoquer avant l'expiration sans liste de refus | Immédiat : supprime l'enregistrement de la session |
| Taille du jeton | Plus grand (~ 200 à 500 octets typiques) | ID de petite session (~ 20 à 40 octets) |
| Utilisation inter-domaines / API | Facile - en-tête de support standard | Nécessite une configuration de partage de cookies |
| Microservices | Idéal – chaque service vérifie localement | Chaque service doit interroger le magasin de sessions |
| Données sensibles dans le jeton | Non chiffré par défaut (utilisez JWE) | Jamais exposé au client |
| Idéal pour | API, microservices, applications mobiles, SSO | Applications Web traditionnelles rendues par un serveur |
Choisissez JWT pour les API distribuées, les microservices, les applications mobiles, l'authentification unique (SSO) et toute architecture dans laquelle plusieurs services indépendants doivent vérifier les jetons sans partager un magasin de sessions.
Choisissez des sessions pour les applications nécessitant une révocation immédiate des jetons (systèmes financiers, outils d'administration), les applications Web traditionnelles rendues par le serveur ou les systèmes où la taille du jeton est une contrainte.
Confidentialité et sécurité
- Fonctionne entièrement dans votre navigateur.Tous les encodages, décodages, vérifications et générations de clés se font côté client via l'API Web Crypto et JavaScript. Que vous encodiez un nouveau jeton ou décodiez un jeton existant, aucune donnée n'est envoyée à un serveur. Comme tous les outils de notre Boîte à outils de sécurité , cet outil est entièrement côté client.
- Rien n'est stocké ou enregistré.Aucun enregistrement n'est conservé des jetons, secrets ou charges utiles que vous saisissez.
- Le codé n’est pas crypté.Les charges utiles JWT (JWS) sont codées en Base64URL et peuvent être lues par toute personne possédant le jeton. La signature numérique rend la charge utile inviolable mais non privée. Pour les jetons qui doivent transporter des données sensibles, utilisez plutôt JWE (JSON Web Encryption, RFC 7516). Cet outil gère uniquement JWS.
- Le décodage n’est pas une authentification.La lecture du contenu d'un jeton ne prouve pas que celui-ci est valide ou digne de confiance. Vérifiez toujours la signature – et validez exp, aud et iss – avant de donner suite à toute réclamation en production.
- Traitez les clés de signature comme des mots de passe.Utilisez le générateur ici pour une clé cryptographiquement aléatoire de la bonne longueur. Stockez-le dans une variable d'environnement ou dans un gestionnaire de secrets dédié. Faites-le pivoter si vous soupçonnez une exposition. Ne le confiez jamais au contrôle de version.
Foire aux questions
Foire aux questions