Décodeur JWT
Signez, vérifiez et lisez la charge utile JWT en ligne, pour simplifier votre flux de travail de développement.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"admin": true,
"iat": 1516239022
}À propos de JWT (JSON Web Tokens)
Un JSON Web Token (JWT) est un format de jeton compact et URL-safe défini dans la RFC 7519. Il se compose de trois parties encodées en Base64Url séparées par des points : un En-tête (algorithme et type de jeton), un Payload (revendications sur l'utilisateur ou la session) et une Signature (preuve cryptographique d'intégrité). Les JWT permettent une authentification sans état — le serveur n'a pas besoin de stocker les sessions, ce qui les rend idéaux pour les systèmes distribués et les microservices.
Avertissement de sécurité
Les JWT sont uniquement encodés en Base64Url, pas chiffrés. Quiconque possède le jeton peut lire son contenu. Ne stockez jamais de mots de passe, numéros de carte de crédit ou autres données sensibles dans un payload JWT. Utilisez HTTPS pour empêcher l'interception en transit.
Les trois parties d'un JWT
- Header: Contient des métadonnées — l'algorithme de signature (par ex. HS256, RS256) et le type de jeton (JWT). Cela indique au serveur comment vérifier la signature.
- Payload: Contient les revendications — paires clé-valeur comme sub (sujet/ID utilisateur), iat (émis à), exp (expiration) et toutes les données personnalisées dont votre application a besoin.
- Signature: Créée en signant l'en-tête et le payload encodés avec une clé secrète (HMAC) ou une clé privée (RSA/ECDSA). Cela empêche la falsification — si quelqu'un modifie le payload, la vérification de la signature échoue.
Signature vs Chiffrement
- JWS (JSON Web Signature): Le format JWT standard. Comme une carte postale avec un sceau inviolable — tout le monde peut lire le contenu, mais personne ne peut le modifier sans briser le sceau. Fournit intégrité et authentification.
- JWE (JSON Web Encryption): Un format JWT chiffré. Comme un coffre-fort verrouillé — seul le destinataire prévu avec la clé de déchiffrement peut lire ce qu'il y a à l'intérieur. Fournit la confidentialité en plus de l'intégrité.
- Nested JWT: Un JWS enveloppé dans un JWE (ou vice versa) pour à la fois la signature et le chiffrement. Utilisé lorsque vous devez garantir à la fois qui l'a envoyé et que personne d'autre ne peut le lire.
Algorithmes de signature courants
- HS256 (HMAC + SHA-256): Symétrique — la même clé secrète signe et vérifie. Simple et rapide, idéal lorsque les deux parties sont de confiance (par ex. un seul service backend).
- RS256 (RSA + SHA-256): Asymétrique — une clé privée signe, une clé publique vérifie. Idéal lorsque des tiers doivent vérifier des jetons sans accès à la clé de signature.
- ES256 (ECDSA + SHA-256): Asymétrique avec courbes elliptiques — clés plus petites et plus rapide que RSA pour une sécurité équivalente. De plus en plus populaire dans les systèmes modernes.
- EdDSA (Ed25519): Algorithme asymétrique haute performance avec de petites signatures. Gagne en adoption pour sa vitesse et ses fortes propriétés de sécurité.
Revendications JWT standard
- iss (Émetteur): Identifie qui a émis le jeton (par ex. l'URL de votre serveur d'auth).
- sub (Sujet): Identifie le principal/utilisateur que le jeton représente.
- aud (Audience): Destinataire(s) prévu(s) du jeton (par ex. votre domaine API).
- exp (Expiration): Timestamp Unix après lequel le jeton n'est plus valide.
- nbf (Pas avant): Timestamp Unix avant lequel le jeton ne doit pas être accepté.
- iat (Émis à): Timestamp Unix de création du jeton.
- jti (ID JWT): Identifiant unique pour le jeton, utile pour empêcher les attaques par rejeu.
Meilleures pratiques de sécurité
- Validez toujours la signature avant de faire confiance au contenu d'un JWT
- Vérifiez la revendication exp et rejetez les jetons expiré
- Validez les revendications iss et aud pour empêcher l'utilisation abusive de jetons entre services
- Utilisez des jetons d'accès à courte durée de vie (5-15 minutes) avec des jetons de rafraîchissement pour les longues sessions
- Stockez les jetons en toute sécurité — préférez les cookies HttpOnly au localStorage pour atténuer les XSS
- Transmettez toujours les JWT via HTTPS pour empêcher l'interception
- N'utilisez jamais l'algorithme none en production — exigez toujours une signature valide
- Effectuez une rotation périodique des clés de signature et supportez l'ID de clé (kid) pour une rotation en douceur
Cas d'utilisation courants
- Authentification utilisateur dans les applications web et mobiles
- Autorisation API entre microservices
- Authentification unique (SSO) sur plusieurs domaines
- Jetons d'accès OAuth 2.0 et jetons d'ID OpenID Connect
- Transmission sécurisée de revendications entre parties dans des webhooks ou systèmes événementiels
Foire Aux Questions (FAQ)
Est-il sûr de décoder les JWT ici ?
Oui. Tout le décodage se fait entièrement dans votre navigateur. Votre JWT n'est jamais envoyé à un serveur, ce qui rend cet outil 100 % côté client et complètement privé. Vous pouvez coller en toute sécurité même des tokens de production pour inspection.
Cet outil vérifie-t-il les signatures ?
Non. Cet outil décode et affiche l'en-tête et la charge utile d'un JWT mais ne vérifie pas la signature cryptographique. La vérification de signature nécessite la clé de signature ou la clé publique, ce qui doit être fait côté serveur.
Puis-je décoder des tokens expirés ?
Oui. Cet outil décode n'importe quel JWT valide quel que soit son statut d'expiration. La revendication d'expiration (exp) est simplement un champ de charge utile qui est affiché avec toutes les autres revendications, vous permettant d'inspecter les tokens qui ont déjà expiré.