Ce qu'est une paire de clés JWT
Un JWT est un jeton d'authentification que ton serveur distribue aux utilisateurs connectés pour qu'ils puissent prouver qui ils sont à chaque requête suivante. Le serveur signe le jeton avec une clé privée, le client le renvoie à chaque requête, et n'importe quel service détenant la clé publique correspondante peut vérifier que la signature était réelle et que le payload n'a pas été modifié en transit.
Pour que tout ça fonctionne, il te faut une paire de clés : une clé privée qui vit sur le serveur qui signe, et une clé publique que tu partages (souvent comme un document JWK publié à `/.well-known/jwks.json`) pour que les vérificateurs puissent contrôler la signature sans jamais voir le secret.
Cet outil génère cette paire de clés pour tout algorithme de signature moderne : RS256/RS384/RS512 (RSA classique), PS256 (RSA-PSS, la variante RSA plus sûre), ES256/ES384/ES512 (courbe elliptique), ou EdDSA (Ed25519, la plus petite et la plus rapide). Tu obtiens les clés en formats PEM et JWK, plus un JWT signé d'exemple que tu peux immédiatement décoder dans le décodeur JWT pour voir le round trip complet. Généré côté serveur avec le `crypto` intégré de Node, jamais stocké.
Comment l'utiliser
- Choisis un algorithme. RS256 est le défaut pour la plupart des setups (Auth0, Okta, Keycloak et AWS Cognito ont tous ça par défaut). ES256 donne des jetons bien plus petits. EdDSA est le chouchou moderne : clés les plus petites, signature la plus rapide, implémentation la plus simple.
- Pour la famille RSA (RS256, RS384, RS512, PS256) : choisis une taille de clé. 2048 bits est le défaut sain. 3072 bits et 4096 bits deviennent exponentiellement plus lents avec un gain de sécurité réel négligeable.
- Pour la famille EC (ES256, ES384, ES512) : la courbe est choisie pour toi automatiquement (P-256, P-384, P-521 respectivement). Ce sont les seules courbes que RFC 7518 autorise pour chaque algorithme.
- Pour EdDSA : on utilise toujours Ed25519, la courbe standardisée par RFC 8037 pour JWS. Pas de boutons à tourner ici.
- Clique sur Générer. On renvoie : la clé privée en PEM, la clé publique en PEM, la clé privée en JWK, la clé publique en JWK, plus un JWT signé d'exemple avec un petit payload (`sub: user-123`, valide pour 1 heure) pour que tu puisses vérifier end-to-end que les clés marchent.
- Sauvegarde la clé privée maintenant. On ne la stocke jamais. Fermer cet onglet la perd à jamais. Installe-la sur ton serveur d'auth, ta API gateway, ou partout où tu émets des jetons.
- Publie la clé publique comme un document JWKS à `https://ton-domaine.com/.well-known/jwks.json`. La plupart des bibliothèques (jose, jsonwebtoken, PyJWT, Microsoft.IdentityModel) peuvent récupérer et mettre en cache cette URL automatiquement.
- Clique sur Ouvrir dans le décodeur à côté du JWT d'exemple pour voir le header, le payload et la signature parsés en direct dans le décodeur JWT. Confirme que le kid dans le header matche le JWK que tu as publié.
Quand c'est utile
Six situations courantes où une nouvelle paire de clés de signature JWT gagne ses galons :
- Configurer un nouveau service d'auth (Keycloak, Ory Hydra, Auth0 self-hosted, un serveur OAuth maison, une API gateway interne). Il te faut la paire de clés avant de pouvoir émettre un seul jeton.
- Migrer de HS256 vers RS256/ES256/EdDSA. HS256 utilise un secret partagé ce qui force chaque vérificateur à détenir le pouvoir de signer. Les algorithmes asymétriques te laissent garder la clé privée sur le serveur d'auth et distribuer la clé publique librement. C'est le chemin de mise à niveau standard pour tout système qui dépasse un service.
- Rotation de clés tous les 3 à 12 mois comme pratique d'hygiène de sécurité. Génère une nouvelle clé sous un nouveau kid, publie les deux clés dans ton JWKS, bascule le signataire vers la nouvelle clé, retire l'ancienne après la période de grâce.
- Suspicion de compromission de clé. Brèche serveur, commit accidentel du PEM sur un dépôt public, ex-employé avec accès aux clés. Génère une nouvelle paire de clés, fais la rotation, révoque l'ancien kid dans JWKS, force-logout les sessions actives.
- Architectures multi-issuer. Chaque service émet ses propres jetons ; chacun reçoit sa propre paire de clés pour que leurs rayons de blast en cas de compromission soient indépendants.
- Tests et démos. Besoin d'un JWT qui marche pour tester une bibliothèque de vérification ? Génère une paire de clés, signe l'exemple, et tu as un vrai exemple end-to-end en un clic.
Outils connexes : décodeur JWT (décoder et inspecter n'importe quel JWT), générateur de paire de clés DKIM, vérificateur bcrypt, hachage de mot de passe, générateur UUID.