Décodez le payload JWT sans vérifier la signature

Il renvoie ces deux parties sous forme d’objets structurés, afin que vous puissiez facilement examiner ou transmettre les claims, identifiants, horodatages, émetteurs, destinataires et métadonnées d’algorithme. La signature n’est volontairement pas vérifiée : les valeurs décodées indiquent ce que le token affirme, sans prouver qui l’a créé. Utilisez le résultat pour le débogage, le développement, la documentation et une inspection prudente, jamais comme preuve d’authenticité ou d’autorisation.

Comprenez ce que le décodage prouve ou ne prouve pas

Un JWT contient généralement un en-tête, un payload et une signature, reliés par des points. Les deux premiers segments sont du JSON encodé en base64url : leur contenu est adapté à un transport compact, mais il n’est ni chiffré ni caché. Cette capacité divise le token fourni, décode ces deux segments en UTF-8, analyse leur JSON et renvoie les objets d’en-tête et de payload obtenus. Elle n’utilise pas le troisième segment pour authentifier quoi que ce soit. Cette distinction est essentielle, car n’importe qui peut fabriquer une chaîne ressemblant à un token avec des claims arbitraires. La présence d’un sujet, d’un rôle, d’un émetteur, d’un destinataire ou d’une expiration dans le payload décodé ne démontre pas qu’un système fiable l’a émis. Servez-vous du décodage pour voir la structure d’un token, diagnostiquer les noms ou valeurs des claims, ou obtenir une représentation lisible pendant le développement. Lorsqu’une décision de sécurité dépend du token, utilisez une bibliothèque de vérification JWT appropriée avec une clé explicitement fiable et des contraintes d’algorithme, d’émetteur et de destinataire.

Fournissez un JWT compact et interprétez la réponse

Collez ou envoyez le JWT compact complet dans le champ token. Un token structurellement valide comporte exactement trois segments séparés par deux points, même si ce décodeur ne lit que les deux premiers. La réponse contient un objet header et un objet payload. Les champs d’en-tête courants comprennent typ, qui identifie souvent le type de média JWT, et alg, qui désigne l’algorithme de signature déclaré. Le payload contient souvent sub pour le sujet, iss pour l’émetteur, aud pour le destinataire, exp pour l’expiration et des claims propres à l’application. Aucun claim n’est exigé : les valeurs JSON présentes sont conservées. Les claims NumericDate tels que exp, nbf et iat restent des nombres au lieu d’être convertis en dates, sans présumer de la façon dont vous souhaitez les afficher ou les comparer. Si le token comporte un nombre incorrect de segments, du base64url mal formé, du UTF-8 ou du JSON invalide, ou une section décodée qui n’est pas un objet, la requête renvoie une erreur d’entrée invalide plutôt qu’un résultat partiel.

Utilisez les claims décodés en toute sécurité

Le décodage est particulièrement utile à la frontière entre systèmes. Une équipe API peut comparer les claims produits par un fournisseur d’identité aux noms attendus par une application. Le support peut examiner un token de test expurgé afin de repérer un destinataire ou un scope manquant. Une suite de tests peut décoder les tokens créés par une fixture locale et confirmer la présence des claims personnalisés requis avant de tester séparément la vérification cryptographique. Gardez toujours la limite de sécurité explicite : les données décodées sont des entrées non fiables. N’accordez pas d’accès, ne choisissez pas de tenant, n’acceptez pas d’identité et n’exposez pas de données privées uniquement parce qu’un claim décodé le demande. Évitez de coller de véritables tokens bearer dans des journaux, tickets, chats ou documents partagés, car un JWT peut être un identifiant actif malgré un payload apparemment inoffensif. Pour vos diagnostics, préférez des exemples synthétiques, expirés ou générés localement. Si une automatisation doit traiter de vrais tokens, transmettez-les uniquement par un canal correctement protégé, puis effectuez une vérification fondée sur une configuration fiable.