Décodeur et vérificateur JWT
Collez un JSON Web Token et lisez-le comme votre serveur devrait le faire : en-tête et charge décodés en JSON lisible, les revendications de temps dessinées en frise — émis, valable à partir de, expire, expiré — et, pour HS256, HS384 et HS512, une vraie vérification de signature contre un secret que vous fournissez. Tout se passe dans votre navigateur. Un jeton est un identifiant, et sur ce site les identifiants ne se collent ni dans des chats IA journalisés ni sur les serveurs d’inconnus.
Ce qu’est un jeton, et ce que le décodage prouve
Un JWT, ce sont trois segments Base64URL joints par des points : un en-tête nommant l’algorithme de signature, une charge de revendications et une signature sur les deux premiers. Le segment central — celui que tout le monde veut lire — est un encodage, pas un chiffrement : le décodeur Base64 l’ouvre sans aucune clé, et c’est pourquoi un jeton ne doit jamais transporter quoi que ce soit que vous n’imprimeriez pas sur une affiche. Ce que la signature ajoute, c’est la provenance : modifiez une revendication et le HMAC ne correspond plus, à condition que le vérificateur vérifie vraiment — les échecs qui remplissent les rapports d’incident sont des serveurs qui ont décodé et fait confiance sans vérifier, des bibliothèques qui ont laissé le jeton choisir son propre algorithme, et des jetons « none » acceptés comme parole d’évangile. Cette page reflète le flux honnête : tout décoder et tout lire, lire la frise des revendications face à l’horloge (un exp dans le passé est un jeton mort, quelle que soit la validité de la signature), tenir compte des alertes d’algorithme, et seulement alors vérifier — localement, le secret restant dans le même onglet du navigateur que le jeton. Si le secret avec lequel vous déboguez venait d’un fichier de configuration, le validateur .env vérifie ce fichier sans le transmettre non plus ; l’article phare, ne laissez jamais un chatbot toucher à vos secrets, explique pourquoi toute la famille d’outils a déménagé dans le navigateur.
Questions fréquentes
Est-il sûr de coller ici un jeton de production ?
C’est l’endroit le plus sûr d’internet pour le faire, et la raison d’être de cet outil. Le décodage se fait dans votre navigateur, dans le code de cette page : le jeton n’est jamais transmis, stocké ni journalisé. Comparez avec les alternatives que les gens utilisent vraiment — les chats IA, qui conservent la conversation sur les serveurs d’un tiers, et les « décodeurs JWT en ligne » dont le serveur voit tout ce que vous collez. Un jeton est un identifiant vivant jusqu’à son expiration ; partout où il est collé, il peut être rejoué depuis là. Ici, il ne va nulle part — la même règle du tout-local que le validateur .env.
Si n’importe qui peut décoder un JWT, pourquoi n’est-ce pas une faille de sécurité ?
Parce que le décodage n’a jamais été la protection. Un JWT est une déclaration signée, pas chiffrée : la charge est du Base64URL — un encodage, lisible par quiconque détient le jeton — et la sécurité vit dans la signature, qui prouve que la déclaration a été émise par le détenteur de la clé et n’a pas été altérée. Le désastre classique, c’est un développeur qui traite la charge comme secrète, ou un serveur qui ne vérifie pas la signature, laissant une charge modifiée à la main passer sans encombre. L’article Base64 n’est pas du chiffrement couvre la confusion d’encodage sous les deux cas.
Pourquoi pouvez-vous vérifier HS256 ici mais pas mon jeton RS256 ?
HS256 est symétrique : un même secret partagé signe et vérifie, donc un secret que vous saisissez peut être contrôlé localement avec HMAC. RS256 est asymétrique : il est signé avec une clé privée et vérifié avec la clé publique correspondante, que cette page devrait vous demander — et une page qui invite à coller des clés enseigne une habitude qui se termine par une clé privée divulguée. Vérifiez les jetons RS256 avec le JWKS publié de l’émetteur dans votre propre code ou vos propres outils, et ne collez jamais une clé privée dans un site web ou un chat, y compris celui-ci.
Que signifie « alg: none » et pourquoi l’alerte rouge ?
Cela signifie que le jeton déclare ne pas être signé — et un serveur qui honore cette déclaration accepte n’importe quelle charge de n’importe qui, sans clé. Ce fut une classe de vulnérabilité réelle et répétée : des bibliothèques qui faisaient confiance au propre champ alg du jeton pouvaient recevoir un jeton « none » avec une charge d’administrateur. L’alerte est bruyante parce que la bonne réponse est bruyante : un jeton none est une donnée non authentifiée, et tout système qui en accepte un a un contournement d’authentification par conception.
La signature est bonne — ai-je terminé ?
Vous avez prouvé que le jeton a été frappé par un détenteur du secret et que son contenu est inchangé. Vous n’avez pas prouvé qu’il vous est destiné (vérifiez la revendication aud), qu’il est actuel (la frise ci-dessus montre exp et nbf), ni que le secret lui-même est fort — HS256 avec un secret devinable comme « secret » tombe sous la force brute hors ligne, après quoi n’importe qui peut frapper des jetons que votre contrôle bénira. La vérification est une ligne de l’audit, pas tout l’audit.