Décodeur JWT

Un JSON Web Token (RFC 7519) est un moyen compact de transmettre des claims entre deux parties : trois segments base64url reliés par des points. L'en-tête indique l'algorithme, la charge utile contient les claims (de qui parle le jeton, qui l'a émis, à qui il est destiné et quand il expire) et la signature permet au destinataire de vérifier que les deux premières parties ont été produites par quelqu'un qui détient la bonne clé et qu'elles n'ont pas été modifiées. Les JWT servent surtout de jetons d'accès OAuth et de jetons d'identité OpenID Connect.

Coupez-le aux points, décodez en base64url les deux premiers segments et analysez chaque résultat comme du JSON. Décoder se résume à cela, et c'est pourquoi aucune clé n'est nécessaire. Collez un jeton dans le champ ci-dessus et le décodage se fait pendant que vous tapez. base64url est du Base64 ordinaire avec le tiret et le tiret bas à la place du plus et de la barre oblique, et sans les signes égal finaux : avec un décodeur Base64 standard, il faut donc d'abord rétablir ces deux caractères.

Seulement sur une page qui le décode localement. Un JWT est un identifiant au porteur : quiconque en détient un non expiré peut généralement l'utiliser. Cette page décode et vérifie dans votre navigateur et n'envoie jamais le jeton nulle part, ce que vous pouvez vérifier vous-même en ouvrant l'onglet Réseau des outils de développement de votre navigateur avant de coller. Malgré tout, privilégiez des jetons expirés ou de test quand c'est possible, et ne collez jamais un secret de signature de production ni une clé privée sur un site que vous ne pouvez pas inspecter.

Oui. Un JWT signé est encodé, pas chiffré. base64url est un encodage de texte réversible et sans clé, donc quiconque voit le jeton peut lire chacun de ses claims. Ne mettez jamais dans la charge utile d'un JWT des mots de passe, des clés d'API ou des données personnelles que vous ne montreriez pas à tous les détenteurs du jeton. Si les claims doivent rester privés, le jeton doit être un JWE, qui est chiffré.

Ce sont des NumericDate : des secondes entières ou fractionnaires écoulées depuis le 1970-01-01 00:00:00 UTC, et non des millisecondes. exp est le moment après lequel le jeton doit être refusé, nbf le moment avant lequel il doit être refusé, et iat le moment où il a été émis. Par exemple, exp 1767225600 correspond au 2026-01-01 00:00:00 UTC. Beaucoup de vérificateurs tolèrent un léger décalage d'horloge, généralement entre zéro et cinq minutes. Une valeur à 13 chiffres est presque toujours un horodatage en millisecondes écrit par erreur, et cette page le signale.

HS256 est un HMAC avec SHA-256. Un seul secret partagé sert à la fois à signer et à vérifier, donc tout service capable de vérifier un jeton peut aussi en créer un. RS256 est une signature RSA avec SHA-256. L'émetteur signe avec une clé privée et n'importe qui vérifie avec la clé publique, que les fournisseurs publient généralement sous forme d'ensemble JWK. HS256 convient à un système unique qui émet et vérifie ses propres jetons ; RS256, ES256 ou EdDSA conviennent aux jetons qui franchissent une frontière de confiance, comme entre un fournisseur d'identité et de nombreuses API.

alg none désigne un JWT non sécurisé : le segment de signature est vide, donc n'importe qui peut y écrire les claims de son choix. La spécification autorise ces jetons, mais un vérificateur qui les accepte, ou qui laisse l'en-tête du jeton choisir l'algorithme à utiliser, peut se voir présenter un jeton falsifié. Configurez votre bibliothèque JWT avec les algorithmes exacts que vous attendez et refusez tout le reste, none compris.

Recalculez-la ou vérifiez-la sur les deux premiers segments, exactement tels qu'ils apparaissent dans le jeton (l'en-tête, un point, puis la charge utile), avec la bonne clé. Pour HS256, cette clé est le secret partagé ; pour RS256, PS256, ES256 ou EdDSA, c'est la clé publique de l'émetteur, généralement disponible au jwks_uri indiqué dans le document /.well-known/openid-configuration du fournisseur. Collez l'un ou l'autre dans le vérificateur ci-dessus. Un vrai vérificateur contrôle ensuite aussi exp, nbf, iss et aud, car une signature valide prouve seulement qui a créé le jeton, pas qu'il est encore acceptable.

Un cookie de session classique contient un identifiant aléatoire que le serveur recherche dans son propre stockage : la déconnexion ou la révocation d'un accès prend donc effet immédiatement. Un JWT transporte ses claims avec lui, donc tout service qui détient la clé peut le vérifier sans recherche, mais il reste valide jusqu'à exp même après la déconnexion de l'utilisateur, sauf si vous ajoutez une liste de révocation. Beaucoup de sites utilisent des JWT de courte durée entre services et une session côté serveur pour le navigateur. Les deux ne s'excluent pas : un JWT peut lui-même être stocké dans un cookie.

Un jeton JSON Web Encryption (RFC 7516) est chiffré, et pas seulement signé. Sa forme compacte compte cinq segments : en-tête protégé, clé chiffrée, vecteur d'initialisation, texte chiffré et tag d'authentification. Seul l'en-tête est lisible ; les claims se trouvent dans le texte chiffré et il faut la clé privée ou la clé partagée du destinataire pour les déchiffrer. Cette page reconnaît un JWE, affiche son en-tête et indique clairement que les claims ne peuvent pas être lus sans la clé.