Gestion des clés de signature pour JWT

Les clés de signature JWT ne sont pas de simples variables de configuration. Elles sont la racine de confiance de chaque jeton créé par l’émetteur. Si une clé de signature fuit, un attaquant peut produire des credentials qui paraissent légitimes jusqu’à ce que rotation et détection rattrapent le problème. Si la gestion des clés est pénible, les équipes repoussent la rotation et gardent des secrets là où c’était pratique au lancement. La dette d’authentification devient alors dette d’incident.

Générer et stocker volontairement

Utilise une génération aléatoire forte depuis un outil fiable ou un KMS. Ne dérive pas des secrets HMAC de noms de produit, de déploiement ou de mots de passe. Pour la signature asymétrique, garde les clés privées hors des dépôts et images conteneur. Le service qui signe les jetons a besoin d’opérations de signature, pas forcément des octets bruts de la clé. KMS, HSM ou service de signature cloud réduisent l’exposition, même si latence et quotas doivent être testés.

Sépare les environnements. Développement, staging et production ne doivent pas partager de clés de signature. Les sandboxes partenaires ne doivent pas accepter les émetteurs production sans design de fédération explicite. Beaucoup d’incidents commencent par une clé staging qui vérifie en production parce que les contrôles d’émetteur et audience étaient faibles.

Contrôler qui peut signer

La vérification peut être large. La signature doit être étroite. Seul le service émetteur devrait créer des jetons utilisateur, et l’outillage administratif devrait passer par un chemin séparé avec audit renforcé. Si chaque backend possède le secret de signature, chaque compromission backend devient compromission du fournisseur d’identité. Préfère un service central de tokens ou une API de signature contrainte avec scopes clairs.

Rotation et audit

Prévois la rotation avant la compromission. Garde des ids de clé uniques, publie les nouvelles clés publiques avant usage, conserve les anciennes jusqu’à expiration des jetons et observe quel kid signe les nouveaux tokens. Audite chaque changement de configuration: qui l’a fait, quel key id, quel environnement et quel déploiement l’a pris. Conserve assez d’historique pour dire si un jeton suspect pouvait être signé par une clé active à ce moment.

Réponse d’urgence

Dispose d’un runbook de compromission de clé. Il doit couvrir la désactivation de la signature avec la clé touchée, la publication du retrait, la réduction des durées de jeton si possible, la révocation des sessions et la communication de l’impact client. Répète-le en staging. Découvrir pendant un vrai incident que les clients mobiles codent en dur une URL JWKS est trop tard.

Le standard utile

Un système sain rend l’action sûre ordinaire: clés générées centralement, matériau privé isolé, accès de signature limité, rotation répétée et traces d’audit lisibles par l’astreinte. Le reste devient un futur chantier d’archéologie sécurité.