JWT Decoder

À 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

Frequently Asked Questions