key Décodeur JWT star

Comment ça fonctionne

Un JSON Web Token est une chaîne compacte composée de trois parties encodées en Base64URL, séparées par des points : header.payload.signature. Base64URL est une variante de Base64 sûre pour les URL : elle remplace +// par -/_ et supprime le remplissage = final, si bien que le résultat peut figurer dans une URL ou un en-tête HTTP sans échappement. L'en-tête est un petit objet JSON qui nomme l'algorithme de signature et le type de token — typiquement {"alg":"HS256","typ":"JWT"}. La charge utile (payload) est un objet JSON de « claims » : des paires clé/valeur arbitraires décrivant qui le token représente et ce qu'il est autorisé à faire, plus quelques claims temporels enregistrés — iat (émis à), nbf (non valide avant) et exp (expiration), tous stockés en timestamps Unix. La signature est calculée sur les deux premières parties à l'aide de l'algorithme nommé dans l'en-tête et d'une clé que seul le serveur émetteur détient.

Collez un token ici et l'outil le découpe sur ses deux points, décode l'en-tête et la charge utile en Base64URL, puis affiche chacun en JSON indenté. Les valeurs exp/iat/nbf éventuelles sont en plus converties en date lisible, avec un badge indiquant en un coup d'œil si le token est actuellement expiré.

Les JWT constituent l'ossature de la plupart des authentifications modernes : tokens d'accès OAuth 2.0, tokens d'identité OpenID Connect et nombreux systèmes de session propriétaires utilisent ce format, car il permet à un serveur d'émettre un identifiant autosuffisant, lisible par d'autres services sans requête en base — tant que la signature peut être vérifiée. Algorithmes courants : HS256 (HMAC à secret partagé) et RS256/ES256 (RSA ou courbe elliptique, où l'émetteur garde une clé privée et chacun vérifie avec la clé publique correspondante).

Ce qu'il faut savoir

Décoder n'est pas vérifier. L'en-tête et la charge utile sont seulement encodés, pas chiffrés, donc n'importe qui peut les lire sans clé — et n'importe qui peut aussi forger un token avec les claims de son choix. Ce qui rend un JWT digne de confiance, c'est exclusivement sa signature, et vérifier une signature nécessite le secret (algorithmes HMAC) ou la clé publique de l'émetteur (algorithmes RSA/ECDSA). Cette vérification doit se faire sur un serveur qui détient la clé ; elle ne peut pas être effectuée en toute sécurité dans un outil de navigateur, car exposer un secret là reviendrait à en annuler l'intérêt. Considérez ce décodeur strictement comme une aide au débogage — jamais comme une preuve qu'un token est authentique ou encore valide.

Faites également attention à ce que vous collez : un JWT transporte des données de session ou d'autorisation, traitez-le comme un mot de passe et évitez de coller des tokens de production réels dans un outil sur une machine partagée. Les tokens à cinq parties sont des JWE (chiffrés), pas des JWS (signés) — ce décodeur traite la variante signée, bien plus courante. Et ne faites jamais confiance aveuglément au champ alg dans votre propre code — une attaque connue piège les implémentations naïves en leur faisant accepter alg: none ou substituer HS256 à RS256 ; d'où l'intérêt de bibliothèques éprouvées plutôt que du code fait maison.