RevealTheme logo

Décodeur de JWT

Décodez des JSON Web Tokens (JWT) instantanément. L'outil s'exécute dans votre navigateur : les tokens ne quittent jamais votre appareil, vous pouvez donc l'utiliser en toute sécurité avec des secrets de production.

Comment utiliser cet outil

  1. 1

    Collez votre JWT dans le champ de saisie.

  2. 2

    Cliquez sur Décoder. L'en-tête et la charge utile sont analysés et affichés.

  3. 3

    Examinez l'algorithme, les claims, l'expiration et l'émetteur.

Qu'est-ce qu'un JWT et comment fonctionne-t-il ?

Un JSON Web Token (JWT, défini dans la RFC 7519) est une manière compacte et sûre pour les URL de représenter un ensemble de revendications (claims) concernant un utilisateur, avec une preuve cryptographique que ces revendications n'ont pas été altérées. Les JWT alimentent l'authentification dans la plupart des piles web modernes : lorsque vous vous connectez, le serveur crée un JWT contenant votre identifiant d'utilisateur et vos autorisations, le signe avec une clé secrète et vous le renvoie. Votre navigateur stocke le token (généralement dans localStorage ou dans un cookie) et l'inclut dans l'en-tête Authorization de chaque requête ultérieure. Le serveur vérifie la signature à chaque requête : si elle est valide, les revendications du token sont dignes de confiance ; si le token a été altéré, la signature ne correspond plus et la requête est rejetée. Les JWT comportent trois parties encodées en Base64URL et séparées par des points : l'en-tête déclare l'algorithme de signature (HS256 pour HMAC-SHA256, RS256 pour RSA, ES256 pour ECDSA, none pour les tokens non signés, ce qui est dangereux et que vous devriez rejeter) ; la charge utile (payload) contient les revendications proprement dites (revendications standard comme « sub » pour le sujet, « exp » pour l'expiration, « iat » pour la date d'émission, ainsi que toute revendication personnalisée définie par votre application) ; la signature est la preuve que l'en-tête et la charge utile ont été signés par quelqu'un détenant le secret. Ce décodeur révèle les deux premières parties, qui sont des informations publiques ; la signature ne peut être vérifiée qu'avec la clé, raison pour laquelle tout décodeur de JWT affiche les revendications sans les vérifier.

Cas d'usage courants

  • Déboguez les problèmes d'authentification en décodant le JWT envoyé par votre client : voyez exactement quels claims sont présents, qui l'a émis et quand il expire.

  • Examinez les JWT des passerelles d'API (AWS Cognito, Auth0, Okta) pour comprendre la structure des claims destinée aux services en aval.

  • Vérifiez que les claims personnalisés (ID d'organisation, rôle, feature flags) sont correctement définis dans le code qui émet le token.

  • Comparez des tokens avant et après un renouvellement pour confirmer que l'expiration a été prolongée.

  • Auditez l'algorithme d'un token : confirmez que RS256 ou ES256 est utilisé en production, jamais 'none'.

  • Traduisez les charges utiles en base64url des journaux du serveur en claims lisibles.

Questions fréquentes

Est-il sûr de l'utiliser avec des JWT de production ?
Oui. Le décodage se produit entièrement dans votre navigateur via du JavaScript local : le token n'atteint jamais nos serveurs ni n'apparaît dans aucun journal. Vous pouvez le vérifier en ouvrant les DevTools → onglet Réseau pendant le décodage : aucune requête sortante n'est déclenchée. Cela dit, traitez les JWT comme des identifiants : ne les collez pas dans des URL, des captures d'écran ou des documents partagés, peu importe où le décodeur s'exécute.
Est-ce que cela vérifie la signature ?
Non. La vérification de la signature nécessite le secret (pour HS256) ou la clé publique (pour RS256/ES256/PS256). Les outils web qui vous demandent votre secret pour vérifier un JWT constituent un signal d'alarme de sécurité : vous enverriez votre clé de signature à un inconnu. Vérifiez les signatures sur le serveur ou avec une bibliothèque que vous contrôlez (jose, jsonwebtoken).
Que se passe-t-il si mon JWT a expiré ?
L'expiration n'empêche pas le décodage : la revendication « exp » n'est qu'une donnée au sein de la charge utile. Recherchez « exp » dans la charge utile décodée : c'est un horodatage Unix (secondes depuis 1970). Convertissez-le avec notre Convertisseur d'horodatage pour voir l'expiration dans votre fuseau horaire. Si « exp » est déjà dépassé, le token est rejeté par tout vérificateur conforme, même si le décodeur continue de le lire.
Les JWT peuvent-ils être chiffrés ?
Oui : cela s'appelle le JWE (JSON Web Encryption, RFC 7516). Cet outil gère les JWS (JSON Web Signature, le cas courant), où la charge utile est signée mais visible. Les tokens JWE comportent 5 parties séparées par des points au lieu de 3 et nécessitent la clé privée du destinataire pour être déchiffrés. Si votre token comporte 5 parties, vous avez besoin d'un outil compatible avec le JWE.
Que signifie « alg » : « none » et est-ce dangereux ?
« none » signifie qu'il n'y a pas de signature : le token est non signé et n'importe qui peut falsifier n'importe quelle revendication. Les systèmes de production doivent explicitement rejeter les tokens avec « alg : none ». Certaines bibliothèques les acceptent par défaut (une catégorie de CVE bien connue). N'autorisez toujours que les algorithmes attendus par votre application.
Pourquoi utiliser des JWT plutôt que des cookies de session ?
Les JWT sont sans état : le serveur n'a pas besoin de consulter une session ; le token lui-même contient l'identité et les autorisations de l'utilisateur. Cela rend les JWT idéaux pour les systèmes distribués et les API. Les cookies de session sont avec état (ils nécessitent un stockage de session côté serveur) mais sont plus faciles à invalider (il suffit de supprimer la session). Le compromis : les JWT s'adaptent mieux à la montée en charge, mais vous ne pouvez pas « déconnecter un utilisateur » avant l'expiration du token.
Quelles sont les revendications standard d'un JWT ?
La RFC 7519 définit : iss (émetteur), sub (sujet, généralement l'identifiant de l'utilisateur), aud (audience), exp (heure d'expiration), nbf (pas avant), iat (émis à), jti (identifiant du JWT). Au-delà de celles-ci, les applications ajoutent des revendications personnalisées comme « roles », « permissions » ou « tenant_id ». Gardez les revendications personnalisées de petite taille : les JWT voyagent dans l'en-tête de chaque requête et augmentent votre consommation de bande passante.

Outils connexes