Gestion des clés
JWK : JSON Web Key, représentation d'une clé cryptographique en JSON (JavaScript Object Notation). « Une clé écrite en clair dans un format que tous les programmes savent lire, et tous les curieux aussi », par analogie avec un trousseau étiqueté, pratique pour qui le possède et pour qui le trouve.
Format : Défini par la RFC 7517 (mai 2015) dans la famille JOSE, un JWK décrit une clé par des membres nommés : kty pour le type (RSA, EC, oct pour une clé symétrique, OKP pour Ed25519 et X25519 selon la RFC 8037), puis les paramètres propres au type, encodés en Base64url. Un JWKS (JSON Web Key Set) est un objet dont le membre keys contient une liste de JWK.
Métadonnées : kid identifie la clé et permet au vérificateur de choisir la bonne dans un JWKS ; use (sig ou enc) et key_ops restreignent l'usage ; alg fixe l'algorithme attendu. La RFC 7638 définit une empreinte canonique (thumbprint), employée notamment par ACME pour identifier un compte.
Public et privé : Le même format porte les clés privées : le membre d, et pour RSA p, q, dp, dq et qi, contient le secret. Un JWKS publié qui embarque par erreur ces membres distribue la clé privée à tous ses visiteurs, ce qui simplifie considérablement la vie des faussaires.
Clé dans le jeton : Un en-tête JWS peut transporter un JWK (paramètre jwk). Un vérificateur qui fait confiance à cette clé vérifie seulement que l'attaquant sait signer avec sa propre clé : c'est la faille CVE-2018-0114 de la bibliothèque node-jose. La clé de vérification doit venir d'une source de confiance, jamais du jeton lui-même.
Ce qui arrive si on s'en passe
Sans format commun comme JWK, chaque fournisseur d'identité publierait ses clés à sa façon et chaque client écrirait son propre analyseur, avec les erreurs de conversion que cela suppose ; la rotation des clés, qui repose sur un JWKS publié et un kid, deviendrait une opération manuelle et risquée. Mal employé, le format a ses propres pièges : membres privés publiés par mégarde, clé de vérification acceptée depuis l'en-tête du jeton, kid utilisé sans contrôle pour aller chercher une clé ailleurs. Publier uniquement les membres publics, fixer l'émetteur et l'algorithme attendus, et récupérer les clés en HTTPS depuis une adresse fixe évitent l'essentiel.
Explication de la marmotte
Une JWK est une façon d'écrire une clé de chiffrement sous forme de texte structuré, dans le format JSON que tous les programmes du web savent lire. Les services qui délivrent des jetons de connexion publient souvent la liste de leurs clés publiques sous cette forme, pour que d'autres services puissent vérifier ces jetons. Il faut veiller à ne publier que la partie publique de chaque clé, jamais la partie secrète.
Où ce terme est utilisé
- Configurer OIDC entre Keycloak et application interne (5 occurrences)
- JWS : signer et sécuriser vos échanges JSON (5 occurrences)
- Formats, bibliothèques et API : rendre la crypto utilisable (3 occurrences)
- JWE : chiffrer un jeton JSON sans se tromper (3 occurrences)
- Authentifier les personnes et les services (2 occurrences)
- Courbes elliptiques : compacité, validation et pièges (2 occurrences)
- Mettre en place la fédération d’identité de charge (2 occurrences)
- OIDC, SAML et OAuth 2.1 en fédération (2 occurrences)
- Partage de données inter-organisations par API (2 occurrences)
- Créer, vérifier et utiliser les clés dès le départ (1 occurrence)
