Décodeur JWT
Décodez et inspectez des JSON Web Tokens localement : en-tête, charge utile et claims d'expiration.
Chargement de Décodeur JWT… Si rien ne se passe, activez JavaScript.
Un JSON Web Token (JWT) est une chaîne compacte et adaptée aux URL qui encode un ensemble signé de claims (des affirmations sur un utilisateur, une session ou une autorisation) dans un format que toute partie détenant la bonne clé peut vérifier de façon indépendante. Défini par le RFC 7519 (2015) et faisant partie de la famille de standards JOSE (signature et chiffrement d'objets JSON), les JWT sont rapidement devenus le mécanisme dominant pour l'authentification sans état et l'autorisation d'API dans les architectures web, mobiles et de microservices. Un JWT se compose de trois segments encodés en Base64url et séparés par des points : l'en-tête (métadonnées de l'algorithme), la charge utile (les claims) et la signature.
Exemples
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.<sig>
Header {"alg":"HS256","typ":"JWT"} · Payload {"sub":"1234567890","name":"John Doe"}
Un JWT est composé de trois parties en Base64url réunies par des points : en-tête.charge_utile.signature.
Questions fréquentes
Mon jeton est-il envoyé à un serveur ?
Quelles sont les trois parties d'un JWT ?
Quand devrais-je utiliser un JWT dans ma propre application ?
En quoi un JWT diffère-t-il d'un cookie de session ?
Cet outil vérifie-t-il la signature du JWT ?
Que signifient les claims d'horodatage standard ?
Un JWT peut-il être utilisé sans signature (alg: none) ?
Les charges utiles des JWT sont-elles privées et confidentielles ?
Quelle est la différence entre HS256 et RS256 ?
Quelle erreur les développeurs commettent-ils souvent avec les JWT ?
À propos de Décodeur JWT
Les JWT apparaissent dans pratiquement tous les flux d'authentification modernes. Les jetons d'accès OAuth 2.0 sont presque universellement émis sous forme de JWT. Les jetons d'identité OpenID Connect sont des JWT qui transportent les claims d'identité de l'utilisateur authentifié. Les systèmes d'authentification unique font transiter des JWT entre fournisseurs d'identité et fournisseurs de services. Les fonctions serverless et les workers de périphérie valident les JWT localement sans consultation de base de données, permettant une authentification sans état et évolutive horizontalement. Les applications mobiles stockent les JWT comme jetons de porteur (bearer) et les incluent dans l'en-tête Authorization de chaque requête d'API. Comprendre ce qu'il y a dans un jeton (quelles autorisations il accorde, quand il expire et qui l'a émis) est une tâche quotidienne pour tout ingénieur backend ou sécurité.
Cet outil décode l'en-tête et la charge utile de n'importe quel JWT entièrement dans votre navigateur. Il décode en Base64url chaque segment, analyse le JSON et présente les claims dans un format lisible. Les horodatages numériques (iat, exp, nbf) sont automatiquement convertis en dates lisibles pour que vous voyiez instantanément si un jeton a expiré. La signature est affichée telle quelle, mais volontairement non vérifiée : la vérification nécessite le secret de l'émetteur (pour HMAC) ou sa clé publique (pour RSA/ECDSA), et vous ne devriez jamais coller l'un ou l'autre dans un outil en ligne non fiable. Comme le décodage se fait localement, même le jeton lui-même ne quitte pas votre appareil.
Quelques points de sécurité à garder à l'esprit : les JWT sont signés mais pas chiffrés par défaut ; la charge utile est simplement encodée en Base64url, ce qui signifie que quiconque intercepte le jeton peut lire ses claims. N'incluez jamais de données personnelles sensibles (mots de passe, numéros de carte) dans la charge utile d'un JWT. L'attaque alg: none est une vulnérabilité connue des bibliothèques JWT naïves qui acceptent les jetons non signés ; utilisez toujours une bibliothèque bien auditée qui valide explicitement l'algorithme. Vérifiez aussi le claim exp avant de faire confiance à un jeton : une signature valide ne signifie pas que le jeton est toujours actif.
L'essor du JSON Web Token
Les JSON Web Token ont été introduits par l'Internet Engineering Task Force (IETF) dans le cadre du groupe de travail JOSE (signature et chiffrement d'objets JSON), avec le RFC 7519 publié en mai 2015. L'objectif était de créer un format d'identifiant compact et autonome capable de remplacer les assertions SAML en XML, verbeuses et complexes, utilisées dans les systèmes d'authentification unique en entreprise. La conception délimitée par des points et encodée en Base64url a été délibérément choisie pour être adaptée aux URL et tenir confortablement dans un en-tête HTTP.
L'adoption a été fulgurante. En quelques années après la publication, presque tous les grands cadres d'authentification, d'Auth0 à Firebase Authentication en passant par AWS Cognito, avaient normalisé les JWT comme format de jeton. Le site jwt.io, lancé par Auth0 comme outil de débogage, est devenu l'un des utilitaires pour développeurs les plus visités d'internet. Cette popularité a aussi attiré l'attention : les chercheurs en sécurité ont catalogué une série de vulnérabilités d'implémentation (le bug 'alg: none', les attaques par confusion d'algorithme) qui affectaient les implémentations de bibliothèques naïves, déclenchant une vague d'améliorations dans les bibliothèques JWT de tous les langages de programmation.
Un choix de conception intéressant des JWT est que la charge utile est lisible par tous : la signature garantit l'intégrité, mais pas le secret. C'était intentionnel : les concepteurs voulaient que les jetons soient débogables sans clé, permettant à des outils comme les décodeurs JWT d'aider les développeurs à inspecter les jetons pendant le développement. Le compromis est que les développeurs doivent être disciplinés quant aux claims qu'ils incluent, une leçon apprise à leurs dépens par des équipes ayant accidentellement livré des JWT contenant des données sensibles d'utilisateurs.