Pourquoi quelqu'un peut-il décoder mon JWT sans le secret ?

Parce que les JWT sont signés, non cryptés. L'en-tête et la charge utile sont simples Base64url - un encodage réversible, et non une cryptographie - et le secret n'est nécessaire que pour créer ou vérifier la signature dans le troisième segment. C'est par conception : les clients ont souvent besoin de lire des réclamations comme l'expiration localement. La règle qui suit : ne mettez jamais de secrets, de mots de passe ou de PII, vous ne montreriez pas l'utilisateur dans une charge utile JWT.

Puis-je décoder un jeton JWT en ligne gratuitement sans rien installer ?

Oui. Collez le jeton, ou toute la valeur de l'en-tête Authorization, dans la zone JWT Token et cliquez sur Décoder ; il est gratuit, pas d'inscription et s'exécute côté client dans la page Vous obtenez l'en-tête et la charge utile comme JSON formaté, chacun avec un bouton Copier, une bannière indiquant si le jeton a expiré et une table convertissant exp, iat et nbf en dates UTC. Seuls les jetons signés à 3 segments décodent ; un jeton chiffré à 5 segments renvoie une erreur.

Pourquoi le tableau des réclamations indique-t-il que mon jeton expire dans des milliers d'années ?

Votre jeton stocke très probablement exp en millisecondes au lieu de secondes La RFC 7519 définit exp, iat et nbf comme secondes depuis 1970, donc une valeur à 13 chiffres telle que 1767229200000 est lue comme une date à des dizaines de milliers d'années et affichée comme valide Divisez par 1000 à l'émetteur Une réclamation stockée sous forme de chaîne, telle que « 1767229200 », n'est pas un nombre et est entièrement laissée hors du tableau L'état est également jugé par rapport à votre propre horloge de périphérique sans marge de manœuvre, donc un jeton de quelques secondes de l'expiration peut lire différemment d'ici un serveur.

Pourquoi cet outil ne vérifie-t-il pas la signature ?

La vérification nécessite la clé de signature - le secret partagé pour HS256 ou la paire de clés privées/publiques pour RS256 - et coller un secret HMAC dans une page Web est exactement l'habitude qui entraîne des fuites de clés. La vérification appartient à votre serveur à l'aide d'une bibliothèque maintenue (JSONWebToken, Jose, Pyjwt). Cet outil répond "Ce qui est dans ce jeton et est-il expiré", qui couvre la plupart des débogages quotidiens.

Mon jeton décode bien mais l'API renvoie 401. Que dois-je vérifier ?

Dans un ordre approximatif de vraisemblance : la réclamation d'EXP est passée (vérifiez la table des réclamations), la réclamation AUD ou ISS ne correspond pas à ce que valide l'API, la clé de signature a été tournée afin que l'enfant dans l'en-tête ne se résout plus, ou que NBF soit quelques secondes à l'avenir en raison de l'horloge entre l'émetteur et le vérificateur. Le décodage vous montre les trois premiers instantanément ; vous avez un diagnostic en comparant IAT à votre propre horloge.

Quelle est la différence entre un JWT et un jeton de session ?

Un jeton de session classique est un identifiant aléatoire opaque ; tout l'état Lives côté serveur, et la suppression d'une session supprime une ligne. Un JWT porte son état en lui-même et est vérifié par la seule signature, de sorte que le serveur n'a pas besoin de magasin de session - idéal pour la mise à l'échelle horizontale et l'authentification inter-service - mais la révocation avant l'expiration nécessite des machines supplémentaires comme un denylist. Ce compromis est la raison pour laquelle le modèle standard est des JWT de courte durée (15 minutes) associés à un jeton de rafraîchissement révocable.

Que signifient exp, iat, nbf, sub, iss et aud ?

Ce sont les réclamations enregistrées de RFC 7519. EXP/IAT/NBF sont des horodatages Unix : lorsque le jeton expire, lorsqu'il a été émis et lorsqu'il commence à être valide. Sub est le sujet (généralement l'ID utilisateur), ISS est l'émetteur (votre serveur d'authentification) et AUD est le public visé (l'API qui devrait l'accepter). Les vérificateurs doivent vérifier EXP, ISS et AUD au minimum - les bibliothèques le font lorsque vous les configurez correctement.

Qu'est-ce que l'attaque ALG : aucune mise en garde cet outil ?

La spécification JWT autorise techniquement "aucun" comme algorithme, ce qui signifie un jeton non signé. Les premières bibliothèques accepteraient un jeton dont l'en-tête revendique Alg:None et saute entièrement la vérification, laissant les attaquants forger des charges utiles arbitraires en éditant simplement la base64. Les bibliothèques modernes le rejettent par défaut, mais le décodeur le signale de toute façon - si jamais vous voyez ALG:NONE sur un vrai jeton, quelque chose ne va pas mal en amont.

Pourquoi mon jeton a-t-il 5 segments au lieu de 3 ?

C'est un JWE - un JWT chiffré - avec des segments pour l'en-tête protégé, la clé chiffrée, la IV, le texte chiffré et la balise d'authenticité. Contrairement à un simple JWS, la charge utile est véritablement cryptée, donc aucun décodeur ne peut le montrer sans la clé de déchiffrement. Cet outil gère la variété commune à 3 segments signée ; un jeton à 5 segments doit être déchiffré par la partie qui détiendra la clé.

Dois-je stocker des JWT dans LocalStorage ou des cookies ?

LocalStorage est lisible par n'importe quel JavaScript sur la page, donc une seule vulnérabilité XSS remet à l'attaquant votre jeton. Un cookie HTTPOnly, sécurisé et identique est invisible aux scripts, qui ferme le chemin XSS-vol au prix d'un besoin de protection CSRF. La plupart des conseils de sécurité arrivent sur les cookies HttpOnly pour le jeton de rafraîchissement, avec le jeton d'accès de courte durée conservé en mémoire uniquement.

Puis-je décoder les jetons expirés ?

Oui - L'expiration n'affecte en rien la décodabilité, car l'EXP n'est qu'un chiffre dans la charge utile. Le décodeur va le signaler en rouge et montrer combien de temps il a périmé, ce qui est souvent exactement ce dont vous avez besoin pour le débogage post-incident : extrayez un jeton des anciens journaux, décodez-le et confirmez s'il était toujours valide au moment de la demande en question.

DÉ

Décodeur JWT

Décodez les en-têtes et les charges utiles de JWT, inspectez les réclamations et vérifiez l'expiration du jeton

JWT Token

Decode only - the signature is NOT verified. No secret required, nothing leaves your browser.

Qu'est-ce que le décodeur JWT ?

JWT Decoder divise un jeton Web JSON en ses trois segments séparant les points, base64url-décèle l'en-tête et la charge utile, et rend les deux en JSON formaté. Les JWT ne sont pas cryptés - le "encodage" n'est que Base64URL, une transformation réversible - ainsi, quiconque détenant un jeton peut lire toutes les revendications à l'intérieur. Cet outil rend cette inspection instantanée : collez un jeton à partir d'un en-tête de cookie Set-cookie, un en-tête d'autorisation (le préfixe de support est supprimé automatiquement) ou le tableau de bord de votre fournisseur d'authentification, et voyez exactement ce que votre serveur y a mis.

Le tableau des réclamations est l'endroit où le débogage se produit Les réclamations temporelles enregistrées - exp (expiration), iat (émis à) et nbf (pas avant) - sont des horodatages Unix, inutiles à lire en brut Le décodeur convertit chacune en une date UTC et une heure relative, affichées comme « Expiré (il y a 3 heures) » ou « Valable (expire en 14 minutes) », et signale les jetons expirés en rouge La plupart des incidents « 401 non autorisés, mais le jeton semble bien » se résument à un exp expiré, un nbf asymétrique, ou une réclamation auditée qui ne correspond pas à ce que l'est l'API valide ici deux secondes - toutes visibles.

Une chose que cet outil ne fait délibérément pas : vérifier les signatures. La vérification nécessite la signature secrète (HS256) ou publique (RS256/ES256), et un outil côté client vous demandant de coller un secret HMAC serait d'enseigner de mauvaises habitudes. Le décodage est à 100 % côté client. Le jeton ne quitte jamais votre navigateur, n'atteint aucun serveur et n'apparaît dans aucun journal des demandes, ce qui compte, car un JWT de production en direct est un identifiant au porteur. Quiconque l'a, c'est vous.

Le décodage n'est pas vérifié, et la distinction est l'ensemble du modèle de sécurité d'un JWT. L'en-tête et la charge utile sont Base64url, non chiffrés, de sorte que toute personne détenant un jeton peut lire toutes les réclamations sans aucune clé. La signature de la signature est la preuve que le contenu n'a pas été modifié et que sa vérification nécessite la clé secrète ou publique, qui est une opération côté serveur. Traitez la charge utile comme une information publique : n'y mettez jamais rien de sensible.

Un moyen rapide de décoder un jeton JWT en ligne et de vérifier le résultat : collez Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsImlhdCI6MTc2NzIyNTYwMCwiZXhwIjoxNzY3MjI5MjI5MjAwfQ.sig et cliquez sur Decode. Le préfixe Bearer est supprimé, le panneau Header affiche {« alg » : « HS256 », « typ » : « JWTywTocket » »1« ,} et le bouton PayWT6 affiche la signature i0, affiche :0, affiche la signature, :0, affiche la fonction de la fonction de visualisation 1, affiche

Comment utiliser le décodeur JWT ?

Collez votre jeton
Déposez le JWT dans la zone de saisie. Saisissez-le à partir de l'en-tête d'autorisation dans l'onglet Réseau de votre navigateur DevTools, un cookie, une storage local ou une réponse de curl. Un préfixe de premier plan "Berer" et un espace blanc environnant sont supprimés automatiquement, de sorte que vous pouvez coller la valeur d'en-tête complète sans nettoyage.
Lire l'en-tête et la charge utile décodées
Les deux segments sont rendus comme JSON formaté côte à côte. L'en-tête vous indique l'algorithme de signature (ALG : RS256, HS256, etc.) et clé ID (KID) - Utile lorsque votre rotation JWK se comporte mal. La charge utile contient les revendications : sous, ISS, AUD, portées, rôles et toutes les données personnalisées que votre couche d'authentification a ajoutées.
Vérifiez la table des réclamations pour l'expiration
Les revendications de temps (EXP, IAT, NBF) sont décodées d'unix secondes en dates lisibles avec des heures relatives. Un EXP expiré apparaît en rouge avec exactement combien de temps il a périmé ; un EXPÉDIT valide apparaît en vert avec le temps restant. Si NBF est dans le futur - généralement l'horloge entre vos serveurs - le jeton sera rejeté même s'il "a l'air" bien.
N'oubliez pas : décodé, non vérifié
Cet outil ne vérifie jamais la signature, qui nécessite la clé secrète ou publique et appartient à votre serveur, et non dans un outil de navigateur. Ne traitez jamais les réclamations décodées comme une entrée fiable : un attaquant peut frapper un jeton avec n'importe quelle charge utile qu'il souhaite. Seule une signature vérifiée prouve que les réclamations sont venues de votre émetteur non modifié.

Principales caractéristiques

En-tête instantané + décodage de la charge utile
Décodage Base64URL en Typescript pur - les deux segments JSON formatés et lisibles immédiatement
Détection d'expiration
Ex-claimation EXPÉDÉE ROUGE A L'EXPRESSION, VERT VERT QU'IL EST VALABLE, AVEC
Réclamations de temps humanisés
EXP, IAT et NBF convertis à partir des secondes brutes Unix en dates ISO et formulation de style "il y a 3 heures"
Tolérant au porteur-préfixe
Collez tout l'en-tête de l'autorisation - "Bearer" et les espaces blancs parasites sont supprimés automatiquement

Frequently Asked Questions

Le décodage lui-même est sûr : il se produit entièrement dans votre navigateur et le jeton n'est jamais envoyé sur le réseau - vérifiez cela dans l'onglet réseau devTools si vous le souhaitez. La mise en garde plus générale est qu'un JWT de production en direct est un identifiant au porteur, alors traitez-le comme un mot de passe partout où vous le collez. Pour les outils tiers non fiables, préférez les jetons ou ceux qui ont expiré dans un environnement de mise en scène.

Related Tools

security

Bcrypt Generator

Generate and verify bcrypt password hashes in the browser with an adjustable cost factor

security

JWT Generator

Generate and sign JSON Web Tokens with HS256, HS384, or HS512, add standard claims, and copy the token. Runs client-side.

security

Password Generator

Generate strong, random passwords with custom character sets and strength analysis

security

Password Strength Checker

Test how strong a password is with an entropy-based strength meter, estimated crack times, and specific suggestions to make it harder to guess - all processed privately in your browser.

Comments

0 comments

No comments yet. Be the first to share your thoughts!

jwtjwt decoderjson web tokendecode jwtjwt debuggertoken decoderjwt claimsexp claimbearer tokendecode jwt token onlinejwt token decode onlinejwt payload viewerinspect jwt claims

En savoir plus

Lisez le guide complet Décodeur JWT

Command Palette

Décodeur JWT

Qu'est-ce que le décodeur JWT ?

Comment utiliser le décodeur JWT ?

Collez votre jeton

Lire l'en-tête et la charge utile décodées

Vérifiez la table des réclamations pour l'expiration

N'oubliez pas : décodé, non vérifié

Principales caractéristiques

En-tête instantané + décodage de la charge utile

Détection d'expiration

Réclamations de temps humanisés

Tolérant au porteur-préfixe

Frequently Asked Questions

Related Tools

Bcrypt Generator

JWT Generator

Password Generator

Password Strength Checker

Comments

En savoir plus