Collez un jeton ou fournissez un payload et un secret de test pour en créer un. Une signature valide ne remplace pas les contrôles d’émetteur, d’audience et d’autorisation.
Fonctionne localement dans votre navigateurInspect a token to view its header.
Inspect a token to view its payload.
Le secret est utilisé uniquement par la cryptographie API de votre navigateur. Ce vérificateur prend en charge HS256, HS384 et HS512 ; il n'envoie pas le jeton ou le secret à VoriTools.
Générez uniquement des jetons HS256, HS384 ou HS512. La payload et le secret restent dans le Web Crypto API de votre navigateur ; cet outil ne propose jamais alg: none.
Generate a local HMAC JWT to view it here.
Les revendications décodées sont des données Base64URL lisibles, et non une preuve qu'un jeton est fiable. Vérifiez son algorithme, son expiration, son émetteur prévu et son public, puis vérifiez sa signature avec une clé de confiance ou un secret avant de l'accepter dans une application.
Cette page sépare un JWT compact en en-tête, charge utile et signature, affiche les claims décodés et vérifie la signature lorsque le jeton est signé en HMAC et que vous fournissez le secret. Elle génère aussi des jetons HS256, HS384 ou HS512 de courte durée à partir d’une charge utile que vous saisissez.
Décoder et vérifier sont deux étapes distinctes à dessein. N’importe qui peut lire la charge utile d’un JWT sans clé, et une signature valide prouve seulement que le jeton a été signé avec cette clé ; elle ne dit ni s’il a expiré, ni pour quel service il a été émis, ni ce qu’il autorise.
L’en-tête est du JSON encodé en Base64URL qui déclare normalement alg et typ, parfois un kid indiquant au vérificateur quelle clé utiliser. La charge utile est l’ensemble des claims : les claims enregistrés (iss, sub, aud, exp, nbf, iat, jti) et ceux que l’émetteur ajoute. La signature est l’algorithme appliqué à la chaîne ASCII base64url(header) + "." + base64url(payload) avec la clé.
Base64URL est l’alphabet Base64 standard avec - et _ à la place de + et /, sans remplissage. C’est pourquoi un jeton passe sans échappement dans une URL, un cookie ou un en-tête Authorization, et pourquoi recomposer un jeton à la main casse presque toujours la signature.
Uniquement la famille HMAC : HS256, HS384 et HS512, car un secret partagé suffit à les recalculer. RS256, PS256, ES256 et EdDSA signent avec une clé privée et se vérifient avec une clé publique : ils peuvent être décodés ici, pas vérifiés ; il faut la JWK publique de l’émetteur. Avec un jeton RS256, le bouton Vérifier la signature reste désactivé et le message l’explique.
Un jeton qui déclare alg: none est signalé en rouge : il ne doit jamais être accepté, et un vérificateur ne devrait jamais se fier à l’algorithme annoncé par le jeton sans le confronter à une liste autorisée. Remplacer HS256 par RS256 et signer avec la clé publique comme s’il s’agissait d’un secret HMAC est une attaque connue contre les bibliothèques négligentes.
exp doit être dans le futur et nbf dans le passé, en secondes depuis l’époque Unix, avec une petite tolérance entre horloges. iat doit être plausible, pas futur. iss et aud doivent correspondre à votre service, sinon un jeton émis pour une autre application sera accepté.
Vérifier la signature n’est pas autoriser. Les rôles, les portées et l’identifiant de locataire vivent dans des claims privés, et l’ensemble des claims d’un JWT est signé mais non chiffré : ne placez jamais un secret dans une charge utile que vous ne montreriez pas au porteur du jeton.
Le décodage et la vérification HMAC s’exécutent dans votre navigateur, le jeton n’est donc pas téléversé. L’habitude sûre reste de tester avec des jetons jetables : un refresh token de production ou un identifiant de longue durée ne devrait être collé sur aucune page web, y compris celle-ci.
Ces algorithmes sont asymétriques et cette page ne recalcule que des signatures HMAC. Le jeton reste décodable et ses claims lisibles, mais le vérifier exige la clé publique de l’émetteur et une bibliothèque compatible JWA, ce qu’une page ne disposant que d’un secret partagé ne peut pas faire correctement.
Soit le secret est faux, soit l’algorithme choisi ne correspond pas à celui de l’en-tête, soit le texte du jeton a changé après la signature. Modifier la charge utile, la réindenter et la réencoder à la main donne le même résultat, car la signature couvre les octets d’origine exacts.
Parce qu’un JWT est signé, pas chiffré. Base64URL est un encodage : quiconque détient le jeton décode l’en-tête et la charge utile sans aucune clé. Si les claims sont sensibles, utilisez JWE, qui chiffre le contenu pour un destinataire.
Le JWT est l’ensemble des claims, les données. Le JWS est la sérialisation signée qui produit le jeton compact en trois parties inspecté ici. Le JWE est la sérialisation chiffrée, où la charge utile est illisible sans clé et où la structure compte cinq parties au lieu de trois.
Quelques minutes, pas des heures. Réglez Expiration en minutes sur une petite valeur pour qu’un jeton de test divulgué cesse vite de fonctionner, et rappelez-vous que cette page signe avec le secret saisi localement : le jeton ne vaut que pour des systèmes partageant ce secret.