Générateur et vérificateur JWT

Comment créer un JWT signé

1. Choisissez l’Algorithme : HS256/384/512 (secret partagé), RS256/384/512 ou PS256/384/512 (RSA), ES256/384/512 (ECDSA sur P-256, P-384 ou P-521) ou EdDSA (Ed25519, si votre navigateur le prend en charge).
2. Modifiez l’En-tête (JSON) et la Charge utile (claims JSON). Le champ alg suit toujours l’algorithme choisi, et typ vaut JWT par défaut.
3. Ajoutez des dates avec les boutons : iat = maintenant, nbf = maintenant, ou choisissez un délai comme « dans 1 heure » puis cliquez sur Définir exp. Ce sont des NumericDate : des secondes écoulées depuis le 1er janvier 1970 UTC.
4. Saisissez le Secret (algorithmes HS, en texte ou en Base64/Base64url selon le Format du secret) ou la Clé privée (PEM ou JWK). Pas encore de clé ? Cliquez sur Générer une clé de test.
5. Cliquez sur Signer le jeton, puis Copier le résultat ou Vérifier ce jeton pour le contrôler aussitôt.

Comment vérifier un JWT

1. Collez le jeton dans Jeton à vérifier.
2. Choisissez l’Algorithme attendu. L’option « Celui de l’en-tête » accepte l’algorithme annoncé par le jeton, sauf none ; un algorithme précis fait refuser tout jeton signé autrement, comme le ferait un vrai serveur.
3. Saisissez le secret ou la Clé publique (PEM ou JWK) : un bloc PEM PUBLIC KEY, RSA PUBLIC KEY ou CERTIFICATE, une JWK ou un JWK Set (la clé dont le kid correspond à l’en-tête est utilisée).
4. Réglez au besoin la Tolérance d’horloge (secondes) pour absorber un léger décalage, puis cliquez sur Vérifier le jeton.

Le résultat indique d’abord si la signature est valide, puis contrôle exp (expiration) et nbf (pas avant) par rapport à l’heure de votre ordinateur. Un jeton correctement signé mais expiré est signalé comme expiré, et non comme valide.

Clés et formats acceptés

Pour signer, l’outil accepte les blocs PKCS#8 PRIVATE KEY, PKCS#1 RSA PRIVATE KEY et SEC1 EC PRIVATE KEY (convertis en PKCS#8 en interne), ainsi que les JWK privées. Une clé protégée par mot de passe doit d’abord être exportée sans mot de passe. Générer une clé de test crée un secret aléatoire de la taille de l’empreinte pour HS, une paire RSA de 2 048 bits pour RS et PS, la courbe adaptée pour ES ou une paire Ed25519. Les clés sont fournies en PEM et en JWK et renseignées des deux côtés : l’aller-retour signature-vérification fonctionne immédiatement.

Les signatures respectent les RFC 7515 et 7518 : RSA-PSS utilise un sel de la longueur de l’empreinte, et les signatures ECDSA sont la concaténation brute r||s. L’implémentation reproduit à l’octet près l’exemple HS256 de l’annexe A.1 de la RFC 7515.

Bonnes pratiques de sécurité

• Tout se passe dans votre navigateur, avec l’API Web Crypto : ni les jetons ni les clés ne sont envoyés. Préférez malgré tout des clés de test aux secrets de production.
• alg: none n’est jamais signé ni accepté.
• Un secret HMAC doit être au moins aussi long que l’empreinte (32 octets pour HS256) ; un secret plus court déclenche un avertissement.
• La signature garantit l’intégrité et l’origine, pas la pertinence des claims : le serveur doit aussi contrôler iss, aud et les droits.