JWT Signer & Verifier

Signez un jeton avec votre propre clé, vérifiez-en un avec un secret, une PEM, une JWK ou une JWKS en direct — et construisez le jeu de clés que votre API publie. Toute la cryptographie tourne dans votre navigateur.

Un JWT ne vaut que sa signature. N’importe qui peut lire un jeton — décoder ne prouve rien — alors cet outil fait la partie qu’un décodeur ne peut pas faire : il signe des jetons avec votre clé (HS256/384/512, RS256/384/512, ES256/384/512, EdDSA), les vérifie avec un secret, une clé publique PEM ou JWK, une JWKS collée ou une URL JWKS en direct avec correspondance de kid, et construit la JWKS que votre propre API publie. Le guide d’accompagnement signer et vérifier les JWT explique pourquoi décoder n’est pas vérifier, comment fonctionne l’attaque par confusion d’algorithme, et ce que « vérifié » prouve — et ne prouve pas. Pour lire un jeton sans clé, utilisez le décodeur JWT ; pour les clés elles-mêmes, la SSH Key Suite couvre la génération et la conversion.

Dernière mise à jour:

Signer un jeton

🔒 La signature et la vérification se font localement avec WebCrypto. Les secrets et les clés privées ne sont jamais envoyés, stockés ni journalisés — rechargez la page et ils ont disparu.

Vos clés ne quittent jamais cette page

La signature et la vérification utilisent WebCrypto, le module de cryptographie de votre navigateur, sur les clés que vous collez ou générez ici. Les secrets et les clés privées ne vivent que dans la mémoire de la page : ils ne sont ni téléversés, ni écrits dans localStorage ou des cookies, et n’apparaissent jamais dans l’URL. Rechargez ou fermez la page, et ils ont disparu. La seule exception est la récupération d’une URL JWKS, que vous lancez vous-même : elle n’envoie que l’URL que vous avez tapée, pour récupérer des clés publiques — jamais un secret. Lisez signer et vérifier les JWT avant de coller une clé de production où que ce soit.

Les limites, honnêtement

EdDSA exige un navigateur récent : WebCrypto Ed25519 n’existe pas dans les navigateurs anciens, et cette page le dit franchement au lieu de simuler une signature. ECDSA P-256 est proposé comme solution de repli qui fonctionne partout.

Les PEM chiffrées (une clé privée verrouillée par une phrase de passe) ne sont pas prises en charge dans la version 1. La page les refuse ouvertement — déchiffrez-la d’abord avec openssl pkcs8 -topk8 -nocrypt, et ne collez jamais une phrase de passe dans une page web.

La récupération d’une URL JWKS dépend des en-têtes CORS envoyés par ce serveur. Beaucoup de fournisseurs d’identité le font ; quand l’un d’eux ne le fait pas, la récupération échoue honnêtement et la page vous invite à coller la JWKS à la place. Seules des clés publiques sont récupérées — une URL JWKS ne transporte jamais un secret.

Quand signer vaut mieux que décoder

Décoder un JWT, c’est le lire : l’en-tête et la charge utile sont en base64url, et quiconque détient le jeton peut voir les deux. C’est pourquoi un décodeur seul ne peut jamais répondre à la seule question qui compte — l’émetteur a-t-il vraiment signé ceci ? Signer est l’autre moitié du travail : celui qui détient la clé privée (ou le secret HMAC) produit la signature, et la vérification rejoue les mêmes mathématiques avec la clé publique. Cette page garde les deux moitiés dans votre navigateur, parce que les clés en jeu sont les entrées les plus sensibles qu’un outil web manipule jamais.

La distinction compte surtout pour les algorithmes asymétriques. Avec HS256, le secret qui vérifie est le même que celui qui signe — quiconque peut vérifier vos jetons peut aussi en forger, ce qui est parfait au sein d’un même service et une fuite partout ailleurs. Avec RS256, ES256 ou EdDSA, la clé de signature reste chez l’émetteur et seule la clé publique voyage : votre API peut publier sa JWKS, faire tourner ses clés en ajoutant un nouveau kid, et laisser tous les vérificateurs du monde vérifier les jetons sans jamais détenir le pouvoir d’en forger un.

Ce que l’outil refuse de faire

Deux refus sont délibérés. Le premier est alg: none : un jeton qui prétend n’avoir besoin d’aucune signature est rejeté d’emblée, avec la raison affichée — un vérificateur qui l’accepte accepte les faux. Le second est la confusion d’algorithme : un jeton RS256 présenté avec un secret HMAC (ou l’inverse) échoue avec un avertissement explicite, sans jamais réinterpréter discrètement la clé dans l’autre famille. Ce sont deux attaques JWT classiques, et les deux sont bloquées structurellement ici — la famille de la clé doit correspondre à la famille de l’alg du jeton, sinon la vérification échoue.

Le troisième refus est plus subtil : cette page ne vous dit jamais qu’un jeton est « digne de confiance ». Une signature valide prouve que le jeton a été signé avec une clé, et le contrôle d’expiration prouve qu’il est dans sa fenêtre — rien de plus. Faire confiance à cette clé ou non est une décision sur son origine : une JWKS récupérée depuis l’URL bien connue de votre fournisseur d’identité, une clé publique que vous avez épinglée vous-même, un secret que vous avez généré. Le guide signer et vérifier les JWT parcourt ce que « vérifié » prouve et ne prouve pas.

Termes JWT, définis précisément

JWT. JSON Web Token (RFC 7519) : un moyen compact et sûr pour les URL de transporter des revendications entre parties — en-tête.charge utile.signature, chacun encodé en base64url. La charge utile est lisible par tous ; seule la signature dépend d’un secret.

JWS. JSON Web Signature (RFC 7515) : le format de signature sous-jacent aux JWT. Un JWT est un JWS dont la charge utile est un ensemble de revendications JSON.

JWK. JSON Web Key (RFC 7517) : un objet JSON représentant une clé cryptographique — kty, et le matériau de la clé (n/e pour RSA, x/y pour EC, x pour Ed25519, k pour un secret partagé).

JWKS. JSON Web Key Set : un objet avec un tableau « keys » — la façon standard pour un émetteur de publier ses clés publiques, généralement à /.well-known/jwks.json.

kid. Key ID : la revendication d’en-tête qui indique quelle clé a signé un jeton. Un vérificateur la compare à la JWKS ; sans elle, un jeu à une seule clé est utilisé et la page le dit.

alg. La revendication d’en-tête qui nomme l’algorithme de signature (HS256, RS256, ES256, EdDSA…). Un vérificateur doit figer les algorithmes qu’il accepte — faire confiance à la revendication alg du jeton lui-même, c’est l’attaque par confusion.

HMAC. Hash-based Message Authentication Code : une signature symétrique — le même secret signe et vérifie. Rapide et simple ; quiconque détient le secret peut forger des jetons.

RSASSA-PKCS1-v1_5. Le schéma de signature RSA derrière RS256/384/512 : l’empreinte est enveloppée puis élevée à l’exposant privé. Déterministe — la même entrée produit toujours les mêmes octets de signature.

EdDSA. Edwards-curve Digital Signature Algorithm : Ed25519 ici — petites clés, vérification rapide, signatures déterministes. Exige un navigateur récent pour la prise en charge WebCrypto.

Questions fréquentes

Est-il sûr de coller une clé privée dans cette page ?

Sur cette page, la clé ne quitte jamais votre navigateur : la signature tourne dans la mémoire de la page avec WebCrypto, rien n’est téléversé, stocké ni journalisé, et un rechargement l’efface. Le schéma dangereux est un signataire côté serveur, où votre clé privée traverse le réseau. Même en local, utilisez un appareil en qui vous avez confiance — et considérez une clé de production collée comme exposée si la machine est partagée. Générez plutôt des clés de test ici au lieu de coller des clés réelles.

Pourquoi mon jeton RS256 ne se vérifie-t-il pas avec mon secret ?

Parce qu’un secret et une clé RSA appartiennent à des familles différentes, et que la page refuse de les mélanger — ce refus est la protection contre la confusion d’algorithme. Un jeton RS256 exige la clé publique RSA de l’émetteur (PEM, JWK ou JWKS) ; un secret ne peut vérifier que HS256/384/512. Si vous détenez la clé publique sous la mauvaise forme, convertissez-la : l’onglet JWKS convertit PEM ⇄ JWK.

Que transmet réellement la récupération d’une URL JWKS ?

Une requête GET vers l’URL que vous avez tapée, demandant du JSON. Aucune clé, aucun secret, aucun jeton ni identifiant ne l’accompagne — la réponse est un jeu de clés publiques. Si le serveur n’envoie pas d’en-têtes CORS, le navigateur bloque la lecture et la page vous invite à coller la JWKS à la place.

Mon jeton se vérifie ici mais l’API le rejette. Pourquoi ?

La vérification ici contrôle la signature et la fenêtre de temps avec la clé que vous avez fournie. Une API contrôle aussi les revendications : l’émetteur (iss) qu’elle attend, l’audience (aud) qu’elle sert, et si l’identifiant de clé (kid) est un identifiant en qui elle a encore confiance. Un jeton signé avec une clé retirée par rotation, ou forgé pour une autre audience, se vérifie mathématiquement et se fait quand même refuser — à juste titre.

EdDSA ne fonctionne pas dans mon navigateur. Que faire ?

Ed25519 exige un navigateur récent — les plus anciens n’ont pas du tout WebCrypto Ed25519, et cette page le dit au lieu de simuler. Utilisez ES256 (ECDSA P-256) comme solution de repli : il est pris en charge partout où WebCrypto existe, et la page peut générer la clé pour vous. Si vous devez absolument utiliser Ed25519, mettez le navigateur à jour.