Why doesn't this tool verify the JWT signature?

Signature verification requires the signing secret or public key, which is kept private on your server. This tool decodes and displays the header and payload for inspection, but cryptographic verification must happen on your backend. Never trust an unsigned or unverified JWT in production.

What information can I see in a JWT payload?

The payload contains claims (data assertions) such as: exp (expiration time), iss (issuer), sub (subject/user), aud (audience), and custom claims. Always check the exp claim to ensure the token hasn't expired. Additional claims depend on how the token was issued.

Is this tool secure for sensitive data?

Yes, all processing runs entirely in your browser. No data is sent to any server, making it safe for sensitive information.

Décodage de JWT en ligne, gratuit

Décodez et inspectez les JSON Web Tokens · en-tête, charge utile, revendications et expiration.

Collez le jeton JWT

En-tête

Charge utile

Signature

À propos des JWT

Les JSON Web Tokens (JWT) sont un moyen compact de représenter des revendications entre deux parties. Ils se composent de trois parties : un en-tête (algorithme et type), une charge utile (revendications telles que l'émetteur, l'expiration, le sujet) et une signature. Cet outil décode l'en-tête et la charge utile, mais ne vérifie pas les signatures · pour cela, vous avez besoin du secret de signature ou de la clé publique. Tout le décodage s'effectue dans votre navigateur ; votre jeton n'est jamais envoyé où que ce soit.

Une brève histoire des JSON Web Tokens

Le JSON Web Token (JWT) a été normalisé en tant que RFC 7519 en mai 2015 par Michael B. Jones (Microsoft), John Bradley (Ping Identity) et Nat Sakimura (NRI) sous l'égide du groupe de travail JOSE de l'IETF. Ce fut l'aboutissement d'une demi-décennie de travail : le premier internet-draft JWT est apparu en décembre 2010, issu du format d'assertion lourd basé sur XML de SAML 2.0 (2005) et du besoin ressenti de quelque chose de plus léger que les navigateurs pouvaient analyser nativement. La percée a été le choix de JSON plutôt que XML et de base64url plutôt que PEM : un JWT pouvait tenir dans une chaîne de requête URL ou un en-tête Authorization: Bearer. Toute la famille JOSE a été livrée comme un ensemble coordonné : RFC 7515 (JWS) pour la signature, RFC 7516 (JWE) pour le chiffrement, RFC 7517 (JWK) pour le format de clé, RFC 7518 (JWA) pour les identifiants d'algorithme et RFC 7519 (JWT) pour la couche de revendications, tous le même jour de mai 2015. L'adoption a été instantanée. OAuth 2.0 (RFC 6749, 2012) avait normalisé les jetons d'accès mais laissé leur format opaque ; l'industrie a choisi JWT. OpenID Connect (décembre 2014, OpenID Foundation) a rendu JWT obligatoire pour les jetons ID. En 2017, tous les principaux fournisseurs d'identité (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) émettaient des JWT comme leur format de session natif. JWT.io, le site web de décodeur lancé par Auth0 en 2014, est devenu l'outil de débogage JWT de facto et a contribué à cimenter la part d'esprit des développeurs envers le format. Deux incidents de sécurité ont façonné le modèle de menace moderne : la divulgation par Tim McLean en 2015 du contournement alg: none et de l'attaque par confusion d'algorithme HS/RS, et CVE-2022-21449 (avril 2022), le bug «Psychic Signatures» de Neil Madden dans le vérificateur ECDSA de Java 15-18. Les deux ont conduit à un durcissement par défaut des bibliothèques : la plupart des bibliothèques modernes refusent désormais alg: none d'emblée et épinglent l'algorithme attendu plutôt que de le lire dans l'en-tête du jeton.

L'anatomie d'un JWT

Trois segments encodés en base64url. Un JWT est la chaîne header.payload.signature : trois segments séparés par des points, chacun encodé en base64url. La RFC 7519 appelle cela la JWT Compact Serialization. Le tout tient dans une URL ou un en-tête HTTP ; cette compacité était l'objectif de conception qui distinguait JWT de ses prédécesseurs basés sur XML comme SAML.
En-tête. Un petit objet JSON contenant généralement deux champs : alg (l'algorithme de signature, par ex. HS256, RS256, ES256) et typ (presque toujours «JWT»). Les champs facultatifs incluent kid (un identifiant de clé utilisé pour la rotation des clés) et cty (type de contenu pour les jetons imbriqués). L'en-tête indique au vérificateur comment valider la signature ; ne lui faites jamais confiance seul, épinglez toujours l'algorithme attendu côté serveur.
Payload. Un objet JSON de revendications, des assertions clé-valeur sur un sujet. La RFC 7519 §4.1 réserve sept revendications standard : iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis à) et jti (ID JWT unique). Les émetteurs ajoutent librement des revendications personnalisées. Le payload est signé mais non chiffré : quiconque possède le jeton peut le lire.
Signature. La preuve cryptographique que l'en-tête et le payload n'ont pas été altérés. L'entrée de signature est la chaîne littérale base64url(header) + "." + base64url(payload) ; la signature elle-même est ensuite encodée en base64url comme troisième segment. La vérification nécessite le secret symétrique (HS*) ou la clé publique asymétrique (RS*, ES*, PS*, EdDSA) et doit toujours se faire sur un serveur de confiance.
base64url, pas base64. Les segments JWT utilisent la variante base64 sûre pour les URL définie dans la RFC 4648 §5 : le caractère 62 est - au lieu de +, le caractère 63 est _ au lieu de /, et le remplissage final = est supprimé. L'atob() intégré de JavaScript ne gère que la base64 standard, donc les décodeurs JWT traduisent l'alphabet et re-remplissent avant de décoder.
NumericDate : secondes, pas millisecondes. La RFC 7519 définit exp, nbf et iat comme «le nombre de secondes depuis 1970-01-01T00:00:00Z UTC». Le Date.now() de JavaScript renvoie des millisecondes, donc un bug courant est un exp trois ordres de grandeur trop grand, produisant un jeton qui «expire» vers l'an 53 000. Utilisez toujours Math.floor(Date.now() / 1000) lors de l'émission de jetons.

Où les JWT sont utilisés en pratique

Jetons d'accès OAuth 2.0. La RFC 6749 a laissé le format du jeton d'accès opaque, mais en pratique l'industrie s'est normalisée sur JWT. Auth0, Okta, Azure AD, AWS Cognito et Google Identity émettent tous des jetons d'accès JWT par défaut. Le jeton Bearer dans votre en-tête Authorization est presque toujours un JWT.
Jetons ID OpenID Connect. OIDC (décembre 2014) impose JWT pour son id_token. L'id_token porte des revendications d'identité sur l'utilisateur authentifié (sub, email, name, picture) et est consommé par la partie utilisatrice plutôt que transmis. C'est le mécanisme principal derrière «Se connecter avec Google», «Se connecter avec Apple» et les flux équivalents.
Authentification d'API. Les API REST sans état adoptent JWT car cela supprime le besoin d'un magasin de sessions côté serveur : l'API fait confiance à ce que la signature vérifie. Les clés API de style Stripe restent courantes pour le trafic serveur-à-serveur, mais pour les API à portée utilisateur, le modèle Authorization: Bearer <jwt> est désormais la valeur par défaut.
Authentification microservice-à-microservice. Un JWT à portée utilisateur émis à la périphérie de l'API est transmis à travers les appels internes service-à-service, permettant à chaque service de faire confiance à l'authentification originale sans re-authentifier. Le modèle est parfois appelé «traduction de jeton» : la passerelle de périphérie échange une session opaque contre un JWT à courte durée de vie limité à l'appel en aval.
Sessions d'applications monopages. Les SPA (React, Vue, Angular) ont historiquement stocké les jetons d'accès dans localStorage par commodité. Les conseils modernes (OWASP, Auth0) sont de conserver les jetons d'accès en mémoire et les jetons de rafraîchissement dans des cookies HttpOnly + Secure + SameSite=Strict, car localStorage est lisible par tout XSS qui atterrit sur la page.
Sessions d'applications mobiles. Les applications iOS et Android stockent les jetons d'accès dans le Keychain ou Keystore de la plateforme. Le jeton est envoyé en tant que Authorization: Bearer à chaque appel backend. Les jetons de rafraîchissement sont alternés à chaque utilisation, et le court exp du jeton d'accès (généralement 5-15 minutes) est la principale défense contre le rejeu en cas de vol d'appareil.

Standards et jalons de sécurité

RFC 7519 (JWT, mai 2015). La spécification de base. Définit la JWT Compact Serialization, les sept revendications standard enregistrées (iss, sub, aud, exp, nbf, iat, jti) et le format NumericDate. Auteurs : Michael B. Jones, John Bradley, Nat Sakimura.
RFC 7515 (JWS, mai 2015). JSON Web Signature. Le format d'enveloppe signée que presque tout le monde appelle informellement «JWT» : trois segments base64url joints par des points. JWS prend en charge les formes de sérialisation compacte et JSON ; JWT n'utilise que la forme compacte.
RFC 7516 (JWE, mai 2015). JSON Web Encryption. La variante chiffrée à cinq segments (en-tête, clé chiffrée, IV, texte chiffré, étiquette d'authentification). Utilisez JWE, pas JWS, lorsque le payload doit être confidentiel et pas seulement résistant à l'altération.
RFC 7517 (JWK, mai 2015). JSON Web Key. La représentation JSON des clés cryptographiques. Le point de terminaison JWKS (/.well-known/jwks.json) publie un ensemble JSON Web Key, le mécanisme moderne pour la rotation de clés sans interruption : les vérificateurs recherchent les clés par kid.
RFC 7518 (JWA, mai 2015). JSON Web Algorithms. Le registre des identifiants alg : HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) et le none (intentionnellement rarement utilisé).
Le contournement alg: none (Tim McLean, 2015). La RFC 7518 liste none comme une valeur d'algorithme valide pour les contextes non sécurisés. Les vérificateurs naïfs acceptaient un jeton avec l'en-tête réécrit à {"alg":"none"} et une signature vide, permettant à un attaquant de falsifier n'importe quel payload. Les bibliothèques modernes refusent none par défaut ; la spécification elle-même indique que les vérificateurs «NE DOIVENT PAS accepter les JWS non sécurisés par défaut».
Attaque par confusion d'algorithme HS/RS (Tim McLean, 2015). Si un vérificateur choisit l'algorithme dans l'en-tête du jeton au lieu de l'épingler, un attaquant peut réécrire l'en-tête à HS256 et signer le jeton en utilisant la clé publique RSA du serveur comme secret HMAC. La bibliothèque voit HS256, traite la clé publique RSA configurée comme un secret symétrique, et la signature est valide. Atténuation : épinglez l'algorithme attendu hors bande ; ne le déduisez jamais du jeton.
CVE-2022-21449 «Psychic Signatures» (Neil Madden, avril 2022). Le vérificateur ECDSA de Java 15-18 ne vérifiait pas que les valeurs r et s de la signature étaient non nulles, ce qui signifie qu'une signature littérale entièrement nulle était acceptée comme valide. Les JWT signés avec ES256/384/512 sur les JVM affectées pouvaient être falsifiés avec une signature vierge. Corrigé dans la mise à jour critique d'Oracle d'avril 2022.

Questions fréquentes supplémentaires

Pourquoi cet outil ne vérifie-t-il pas la signature ?

La vérification nécessite un secret (HMAC) ou une clé publique (RSA / ECDSA / EdDSA). Coller un secret HMAC de production sur un site web est en soi une fuite de credentials, même sur un outil qui jure ne rien transmettre. La vérification appartient à un serveur que vous contrôlez. Le rôle du décodeur est de rendre le contenu lisible pour que vous puissiez voir ce que votre vérificateur devrait vérifier.

Est-il sûr de coller de vrais jetons de production ici ?

Le décodage se fait entièrement dans votre navigateur. Le jeton n'est pas envoyé sur le réseau, écrit dans aucun journal, ni stocké nulle part. Cela dit, un JWT est souvent un credential : quiconque détient un jeton d'accès non expiré peut agir comme l'utilisateur. La convention communautaire est «traitez un JWT de production comme un cookie de session» : préférez les jetons de test quand vous le pouvez, et faites tourner tout jeton réel que vous avez partagé en dehors de la session de navigateur qui l'a émis.

Où devrais-je stocker un JWT dans le navigateur ?

Les deux modèles courants ont chacun un compromis. localStorage est pratique mais lisible par toute attaque XSS réussie sur la page. Les cookies avec HttpOnly sont invisibles pour JavaScript donc XSS ne peut pas les lire, mais ils ont besoin de SameSite=Strict ou SameSite=Lax pour éviter CSRF. La meilleure pratique actuelle : jetons d'accès à courte durée de vie dans une variable JavaScript (mémoire uniquement) plus un jeton de rafraîchissement à longue durée de vie dans un cookie HttpOnly + Secure + SameSite=Strict limité au point de terminaison de rafraîchissement, alterné à chaque utilisation.

Que fait le champ kid dans l'en-tête ?

Il identifie quelle clé a signé le jeton. Les fournisseurs d'identité modernes publient leurs clés publiques sur un point de terminaison /.well-known/jwks.json sous forme d'ensemble JWK (RFC 7517) ; le vérificateur recherche la clé dont le kid correspond à l'en-tête du jeton. C'est ce qui rend possible la rotation de clés sans interruption : les anciennes et nouvelles clés peuvent coexister dans le JWKS pendant la période de grâce.

Puis-je révoquer un JWT une fois émis ?

Pas nativement. Un JWT signé est valide jusqu'à sa revendication exp ; cette absence d'état est la propriété phare du format. Solutions de contournement : garder les jetons d'accès courts (5-15 minutes) associés à un jeton de rafraîchissement révocable ; maintenir une liste de refus côté serveur des valeurs jti révoquées ; faire tourner la clé de signature (ce qui invalide tous les jetons en cours signés avec elle). Chaque option réintroduit un certain état ; c'est le compromis.

Décoder un jeton est-il la même chose que le déchiffrer ?

Non. Le décodage inverse base64url vers JSON : tout le monde peut le faire, et c'est le but. Le déchiffrement nécessite une clé et ne s'applique qu'à JSON Web Encryption (JWE, RFC 7516), qui est la variante chiffrée de la famille JOSE. La plupart des jetons que vous voyez dans la nature sont des JWS (signés mais non chiffrés), donc le décodage suffit à les lire.