Vérifiez localement les signatures JWT HS256, HS384 ou HS512 avec un secret UTF-8 littéral et distinguez structure, exp, nbf et iat. Conçu pour les développeurs qui valident l'intégrité de tokens avant d'accorder l'accès. Vérification cryptographique réelle, pas seulement décodage.
Outils JWT
Jeton JWT
Glisser-déposer pris en charge
Résultat de vérification
Collez un jeton JWT à gauche.
Le vérificateur contrôle HMAC pour HS256/384/512 et l’état NumericDate de base, mais pas RSA/ECDSA, émetteur, audience, nonce ou autorisation.
Suivez ce flux propre à Vérificateur HMAC JWT ; chaque étape correspond aux commandes et limites réelles de l’espace de travail dans le navigateur.
Étape 1
Collez ou importez exactement le token compact en trois segments en conservant les octets header.payload.
Étape 2
Vérifiez que alg vaut HS256, HS384 ou HS512 et saisissez le secret littéral, sans décoder automatiquement Base64 ou hex.
Étape 3
Gardez Live ou lancez Valider pour appliquer Web Crypto à l’entrée signée originale.
Étape 4
Examinez séparément structure, algorithme, verdict de signature, erreurs exp/nbf et avertissement iat futur.
Étape 5
Avant acceptation, imposez algorithme, émetteur, audience, nonce, tolérance temporelle et autorisations dans l’application.
Conséquence: TextEncoder encode les caractères tels quels ; ils ne correspondent pas aux octets représentés par Base64 ou hex.
Correction: Entrez le même secret littéral que l’émetteur ou utilisez un vérificateur important explicitement le format de clé.
Conséquence: La structure peut réussir avec secret absent, algorithme non pris en charge ou HMAC faux.
Correction: Exigez le verdict explicite Signature valide et lisez séparément toute erreur ou alerte.
Conséquence: Les algorithmes asymétriques demandent la bonne clé publique et un import approprié ; seules les variantes HMAC SHA-2 sont implémentées.
Correction: Employez une bibliothèque JOSE maintenue avec JWK/JWKS fiable et politique stricte iss/aud/alg.
Inspectez alg et claims, vérifiez la signature compacte avec le secret exact, puis appliquez les règles iss/aud de l’application.
La signature est HMAC-SHA-256 sur les deux premiers segments avec la clé UTF-8 « your-256-bit-secret » ; aucun exp n’est présent.
Uniquement HS256, HS384 et HS512 ; les autres restent analysables mais reviennent comme non vérifiés.
Non. L’API doit faire confiance à la clé/iss, exiger aud/alg, contrôler durée/nonce et autoriser sujet et scopes.
TextEncoder transforme exactement la saisie en UTF-8 ; aucun décodage Base64, hex, JWK ni dérivation n’a lieu.
Intégrité et durée sont indépendantes ; exp à ou avant la seconde Unix courante produit une erreur malgré un HMAC correct.
Non. Il contient structure, algorithme et état de signature ; le secret reste toutefois dans le champ et la mémoire jusqu’à effacement.
Token et secret sont utilisés uniquement en mémoire par Web Crypto, sans téléversement ni inclusion du secret dans le rapport. Effacez les champs et le presse-papiers à la fin.
