Décoder JWT en Ligne
Décode les tokens JWT dans ton navigateur — aucune donnée envoyée à aucun serveur.
Pourquoi l'utiliser
Débogue tes tokens JWT instantanément
100% privé
Le décodage se fait dans ton navigateur. Ton token ne quitte jamais ton appareil.
Instantané
Décodage en temps réel pendant que tu tapes. Sans boutons, sans attente.
JSON formaté
Header et payload affichés en JSON lisible avec une coloration syntaxique correcte.
Tous les types JWT pris en charge
Fonctionne avec HS256, RS256, ES256 et tout algorithme du standard JOSE.
Comment ça marche
Trois étapes, sans complications
Colle ton token JWT
Copie-colle n'importe quel JWT dans le champ de saisie. Le format est trois parties séparées par des points : header.payload.signature.
Décodage instantané
Le header et le payload sont décodés depuis Base64URL et affichés en JSON formaté. Tu vois le type d'algorithme, l'émetteur, l'expiration et toutes les claims.
Analyse les données
Examine chaque champ du payload : iss (émetteur), sub (sujet), exp (expiration), iat (émis le), aud (audience) et toutes les claims personnalisées.
FAQ
Des questions ?
JWT (JSON Web Token) est un standard ouvert (RFC 7519) qui définit une façon compacte et auto-contenue de transmettre des informations entre parties sous forme d'objet JSON. Le token est signé numériquement, ce qui permet de vérifier son authenticité. Il est largement utilisé pour l'authentification et l'autorisation dans les API REST et les applications web modernes.
Quand un utilisateur se connecte, le serveur crée un JWT signé avec une clé secrète (HS256) ou une clé privée (RS256) et l'envoie au client. Le client stocke le token (généralement en mémoire ou dans le localStorage) et l'inclut dans chaque requête sous la forme Authorization: Bearer token. Le serveur vérifie la signature du token sans interroger une base de données, ce qui fait de JWT un mécanisme d'authentification sans état (stateless) qui s'adapte bien aux systèmes distribués.
Un JWT est signé, pas chiffré. Cela signifie que n'importe qui peut décoder le payload et lire son contenu — c'est pourquoi tu ne dois jamais inclure de mots de passe, numéros de carte bancaire ou données sensibles dans le payload. La signature garantit l'intégrité (personne ne peut modifier le token sans l'invalider) mais pas la confidentialité. Si tu as besoin de chiffrer le contenu, utilise JWE (JSON Web Encryption).
Les claims sont des déclarations sur le sujet du token. Les claims enregistrées (RFC 7519) incluent : iss (issuer), sub (subject), exp (expiration, timestamp Unix), iat (issued at), aud (audience), nbf (not before) et jti (JWT ID). Au-delà de celles-ci, tu peux inclure n'importe quelle claim personnalisée dont ton application a besoin.
Pas sans l'invalider. Si tu modifies n'importe quelle partie du header ou du payload sans avoir la clé secrète pour le re-signer, la signature résultante sera incorrecte et le serveur rejettera le token. Des vulnérabilités connues existent néanmoins : l'attaque alg:none (où le header déclare l'absence d'algorithme pour contourner la vérification) et la confusion d'algorithmes RS256/HS256. Utilise toujours une bibliothèque JWT bien maintenue qui gère explicitement ces cas.
Les cookies de session stockent un ID sur le serveur (stateful), tandis que JWT contient toutes les informations dans le token lui-même (stateless). JWT s'adapte mieux aux architectures distribuées et aux microservices car il ne nécessite pas de sessions partagées. Cependant, JWT a des inconvénients : tu ne peux pas révoquer un token avant son expiration sans infrastructure supplémentaire (liste noire), et si le token est volé il reste valide jusqu'à expiration. Pour la plupart des applications web traditionnelles, les cookies de session httpOnly restent le choix par défaut le plus sécurisé.
JWT : histoire, structure technique et sécurité en profondeur
JSON Web Token a été standardisé par l'IETF en mai 2015 sous la référence RFC 7519, dans le cadre du framework JOSE (JSON Object Signing and Encryption). JOSE comprend également JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) et JWA (JSON Web Algorithms, RFC 7518). Les travaux sur ce standard ont débuté en 2011, menés par Mike Jones (Microsoft), John Bradley et Nat Sakimura. Avant JWT, les développeurs utilisaient SAML (Security Assertion Markup Language), un standard basé sur XML considérablement plus verbeux et complexe.
Un JWT est composé de trois parties encodées en Base64URL séparées par des points. Base64URL diffère de Base64 standard en remplaçant le signe + par - et le / par _, et en omettant le rembourrage =, ce qui le rend sûr à utiliser dans les URL et les en-têtes HTTP sans encodage supplémentaire. Le header spécifie le type de token (typ: JWT) et l'algorithme de signature (alg). Les algorithmes les plus courants sont HS256 (HMAC-SHA256, clé symétrique), RS256 (RSA-SHA256, clé asymétrique), ES256 (ECDSA-SHA256, courbe P-256) et le dangereux none (sans signature, qui ne doit jamais être accepté en production).
Les vulnérabilités JWT les plus critiques sont bien documentées dans le Top 10 de l'OWASP API Security. La vulnérabilité alg:none (CVE-2015-9235 dans plusieurs bibliothèques) permet à un attaquant de modifier le header pour déclarer qu'aucune signature n'est nécessaire, le serveur acceptant alors n'importe quel payload si la bibliothèque ne valide pas explicitement l'algorithme. La confusion RS256/HS256 se produit quand un serveur configuré pour RS256 accepte aussi HS256 : l'attaquant peut utiliser la clé publique RSA (qui est par définition publique) comme clé secrète HMAC pour signer des tokens frauduleux. Les bibliothèques modernes comme jose, python-jose et jsonwebtoken résolvent ces problèmes en exigeant que l'algorithme soit spécifié explicitement lors de la vérification.