Décoder un JWT

Non — et pour cette page, c'est tout l'enjeu plutôt qu'une simple fonctionnalité. Un JWT est généralement un identifiant actif : quiconque le détient peut agir en votre nom jusqu'à son expiration. Le coller dans un décodeur en ligne qui l'envoie à un serveur, c'est remettre une clé qui fonctionne, et aucune promesse de non-journalisation ne peut l'annuler. Ce décodeur est du simple JavaScript dans la page que vous consultez. Rien n'est conservé, rien n'est journalisé, aucune requête n'est effectuée. Une fois la page chargée, coupez votre Wi-Fi : elle fonctionne exactement de la même façon. C'est le moyen le plus simple de vérifier vous-même la promesse de confidentialité, plutôt que de nous croire sur parole.

Non, et aucun décodeur en ligne ne peut honnêtement le faire sans votre clé de signature. Décoder et vérifier sont deux opérations complètement différentes. Décoder consiste simplement à défaire le Base64 du jeton — n'importe qui peut le faire sur n'importe quel jeton, et cela ne prouve absolument rien quant à son authenticité. Vérifier, c'est recalculer la signature avec le secret ou la clé publique qui l'a signé, et cette clé ne doit jamais être collée dans un site web. Ce que vous voyez ici, c'est ce que le jeton AFFIRME. Savoir si ces affirmations sont dignes de confiance est une question à laquelle seul votre serveur, qui détient la clé, peut répondre.

Oui — intégralement, et beaucoup de gens l'ignorent. Un JWT est signé, pas chiffré. L'en-tête et le payload sont en Base64, un encodage sans aucun secret : quiconque intercepte le jeton peut lire chacune de ses claims. La signature l'empêche de MODIFIER le jeton ; elle ne fait rien pour l'empêcher de le LIRE. Ne mettez jamais rien de confidentiel dans le payload d'un JWT : pas de mots de passe, pas de numéros de carte, aucune donnée personnelle que vous n'écririez pas sur une carte postale.

Que le jeton se déclare non signé, et c'est l'un des constats les plus graves que cette page puisse signaler. `alg: none` est un contournement d'authentification documenté : un attaquant prend un vrai jeton, modifie le payload pour se déclarer administrateur, règle l'algorithme sur « none », supprime la signature, et une bibliothèque qui fait confiance à l'en-tête l'accepte. Toutes les bibliothèques JWT sérieuses bloquent désormais cela par défaut, mais des implémentations qui font confiance à `alg` existent encore. Un jeton qui arrive avec `alg: none` doit être traité comme une attaque jusqu'à preuve du contraire.

C'est fait pour vous. `exp`, `iat` et `nbf` sont des horodatages Unix — des secondes depuis 1970 — illisibles sous forme de nombres bruts. Chacun s'affiche comme une vraie date dans votre fuseau horaire, avec le temps écoulé ou restant, et un jeton expiré est signalé clairement au lieu de vous laisser le déduire. Un jeton sans aucun `exp` est également signalé : un JWT qui n'expire jamais ne peut pas être révoqué par expiration, et reste valide aussi longtemps que la clé de signature.

C'est alors un JWE — chiffré et pas seulement signé — et son contenu ne peut réellement pas être lu sans la clé de déchiffrement. La page reconnaît cette forme et vous le dit, au lieu de vous afficher du charabia. Cinq parties signifient que le payload est un vrai texte chiffré ; il n'y a rien à décoder.

Les claims enregistrées sont : `iss` l'émetteur, `sub` le sujet (généralement un identifiant d'utilisateur), `aud` le destinataire, `exp` la date d'expiration, `nbf` la date avant laquelle le jeton n'est pas valide, `iat` la date d'émission, et `jti` un identifiant unique du jeton. Tout le reste est propre à celui qui a conçu le système. Chaque claim enregistrée est accompagnée de sa signification dans le résultat : inutile de retenir quelle abréviation de trois lettres correspond à quoi.