Décodeur JWT

Collez un JWT (JSON Web Token) pour décoder instantanément son en-tête et sa charge utile, avec vérification de la date d'expiration (exp). Aucune vérification de signature n'est effectuée et aucune clé secrète n'est requise.

Principales revendications enregistrées (Registered Claims)

Revendication Nom Description
iss Issuer (émetteur) Chaîne ou URL identifiant l'entité ayant émis le token.
sub Subject (sujet) L'entité désignée par le token (généralement un identifiant utilisateur).
aud Audience (destinataire) Identifiant du destinataire ou de l'API auquel le token est destiné.
exp Expiration Time (expiration) Instant (en secondes Unix) à partir duquel le token ne doit plus être accepté.
nbf Not Before (valide à partir de) Instant (en secondes Unix) avant lequel le token ne doit pas être accepté.
iat Issued At (date d'émission) Instant (en secondes Unix) auquel le token a été émis.
jti JWT ID Identifiant unique du token, souvent utilisé pour détecter les attaques par rejeu (replay).

Astuces

  • Le JWT que vous collez est traité entièrement en JavaScript dans votre navigateur et n'est jamais envoyé aux serveurs de toolbase.cc : les informations personnelles ou d'authentification qu'il contient restent donc confidentielles.
  • Un JWT est une chaîne Base64URL composée de trois parties — en-tête, charge utile et signature — séparées par des points. L'en-tête et la charge utile sont du texte en clair que n'importe qui peut décoder (le Base64 est un encodage, pas un chiffrement) : n'y placez donc jamais d'informations sensibles comme des mots de passe.
  • Si une requête API échoue avec une erreur 401 à cause d'un token expiré, vérifier la valeur de la revendication exp avec cet outil est souvent le moyen le plus rapide d'en confirmer la cause.
  • L'algorithme de signature est indiqué dans l'en-tête alg. Les implémentations qui acceptent alg: none sont vulnérables à l'attaque bien connue « alg=none » des JWT, qui contourne la vérification de signature ; le serveur doit donc toujours restreindre explicitement les algorithmes autorisés.

Questions fréquentes

Oui. L'en-tête et la charge utile d'un JWT sont encodés en Base64URL, pas chiffrés, si bien que n'importe qui peut en lire le contenu. Des informations sensibles comme des mots de passe ou des numéros de carte bancaire ne doivent jamais figurer dans la charge utile.

Non, cet outil se contente de décoder et d'afficher l'en-tête et la charge utile ; il ne vérifie pas la signature. Cette vérification nécessite une clé secrète (ou une clé publique RSA/EC) connue uniquement de l'émetteur du token, et saisir une telle clé dans un outil de navigateur constituerait en soi un risque de sécurité.

La plupart des API et serveurs d'authentification rejettent un JWT dont la revendication exp est antérieure à l'heure actuelle, en renvoyant généralement une erreur 401 Unauthorized. Il faut alors obtenir un nouveau token, par exemple via un refresh token.
ツールくん

Anecdote — comment le JWT rend possible l'« authentification sans état »

Le JWT (JSON Web Token) a été standardisé par l'IETF sous la référence RFC 7519 en 2015. L'authentification classique par session obligeait le serveur à conserver une table de correspondance entre identifiants de session et données utilisateur, tandis que le JWT intègre directement les informations de l'utilisateur dans le token et utilise une signature pour détecter toute altération. Le serveur peut ainsi vérifier l'état d'authentification sans conserver de magasin de sessions — une approche dite « sans état » (stateless) — ce qui explique la large adoption du JWT dans les systèmes distribués et l'authentification entre microservices répartis sur plusieurs serveurs.

Un JWT se compose de trois parties — « en-tête.charge utile.signature » — chacune encodée en Base64URL et reliées par des points. Le point essentiel est que l'en-tête et la charge utile sont simplement encodés, et non chiffrés. N'importe qui peut les décoder et en lire le contenu : un JWT garantit donc que les données n'ont pas été altérées, mais pas que leur contenu reste secret. Pour préserver la confidentialité d'informations, il faut recourir à une spécification distincte ajoutant un véritable chiffrement, appelée JWE (JSON Web Encryption).

Les méthodes de signature se répartissent globalement en deux catégories : les méthodes HMAC (comme HS256), où l'émetteur et le destinataire partagent la même clé secrète, et les méthodes à clé publique (comme RS256 et ES256), où une clé privée signe le token et une clé publique le vérifie. Depuis que le JWT a été adopté comme format des tokens d'accès et d'identité d'OAuth 2.0 et d'OpenID Connect, il est devenu le format standard de facto de l'infrastructure d'authentification sur le Web.