06. JWK, kid et choix des clés

Comprendre le mécanisme

Un JWK représente une clé avec des paramètres et métadonnées. Un jeu public de clés ne doit contenir que les éléments publics attendus. Le champ kid peut aider à sélectionner une clé ; il n’authentifie ni le token ni la destination réseau. Des clés de même identifiant dans des contextes différents ne doivent pas se confondre : issuer, usage et algorithme font partie de la résolution.

Raisonner et vérifier

Ne transformez jamais kid en chemin de fichier libre ni jku en URL de téléchargement arbitraire. Le jeu de clés est lié à un fournisseur admis. Borner réponse, délai, cache et renouvellement protège aussi contre l’abus de tokens à identifiants inconnus. Si la clé ne peut pas être résolue selon le contrat, refusez l’accès ; un ancien résultat positif ne doit pas faire accepter n’importe quelle signature.

Référence hostile

kid est une référence non fiable à résoudre. La référence ne prouve ni clé ni émetteur. kid vient du token reçu et doit être traité comme une donnée non fiable. Résolvez-le dans une table ou un jeu de clés maîtrisé plutôt que le convertir directement en chemin, requête ou URL.

Contexte de sélection

Une résolution peut dépendre de issuer et usage. Le contexte de confiance compte. Un même identifiant peut exister chez deux fournisseurs. La résolution doit tenir compte de l’émetteur admis et de l’usage attendu afin d’éviter qu’une clé valide dans un autre contexte soit choisie.

Jeu public

Le jeu public ne doit pas exposer les paramètres privés. La vérification asymétrique utilise les données publiques. Une JWKS publique destinée à vérifier des signatures ne doit contenir que les paramètres publics prévus. Vérifiez les exports afin qu’une sérialisation d’objet de clé n’ajoute pas ses paramètres privés.

URL contrôlée

Une URL de clés doit être maîtrisée. Cela peut détourner la confiance et les sorties réseau. Une valeur jku arbitraire peut diriger le serveur vers une destination hostile ou interne. Partez d’une configuration de fournisseur maîtrisée et appliquez aussi la politique de sorties réseau.

Aucun chemin libre

kid ne doit pas devenir un chemin libre. Le client ne doit pas sélectionner arbitrairement des fichiers. Concaténer ../other-secret à un répertoire de clés permet une traversée de chemin. Une table de références exactes évite de donner au porteur une capacité générale de lecture du système de fichiers.

Clé inconnue

Une clé inconnue doit suivre une actualisation bornée. Une entrée hostile peut sinon amplifier le travail. Une rotation peut justifier une actualisation JWKS, mais celle-ci doit être bornée et mutualisée. Des kid aléatoires en rafale ne doivent pas provoquer un appel externe coûteux pour chaque requête.

Ambiguïté

Un jeu ambigu demande une politique explicite. La résolution doit rester déterministe et sûre. Deux clés portant le même identifiant ou des usages incompatibles demandent un refus ou une politique explicite. Ne choisissez pas simplement le premier élément si cette règle n’établit pas une correspondance sûre.

Paramètres compatibles

Les paramètres de clé doivent être compatibles. Le type de clé fait partie de la validation. Contrôlez type de clé, usage et algorithme selon le profil. La présence d’un kid connu ne donne pas à une clé la capacité de vérifier n’importe quelle famille cryptographique.

Sélection puis preuve

Sélectionner une clé ne vérifie pas encore la signature. La preuve doit être vérifiée avec la clé sélectionnée. Trouver la clé ne valide pas la signature. Gardez ces étapes distinctes et vérifiez qu’un token altéré avec un kid existant est encore refusé avant tout traitement métier.

Cycle de cache

Le cache doit avoir un cycle documenté. Rotation et incident peuvent modifier les attentes. Documentez durée, rafraîchissement, panne et invalidation en incident. Un cache améliore la disponibilité mais peut retarder le retrait d’une clé compromise si aucune politique spécifique n’est prévue.

Atelier guidé : lire, expliquer et vérifier le code

<?php
declare(strict_types=1);
$kid = '../other-secret'; // entrée simulée non fiable
$path = '/srv/lab/keys/'.$kid.'.pem';
echo $path;

La concaténation de kid dans un chemin transforme une référence hostile en accès au système de fichiers. Ne cherchez pas seulement à retirer les deux points : remplacez cette résolution libre par une sélection dans le jeu de clés admis pour le fournisseur et l’usage du token.

Une extension ne valide pas la provenance ni le droit de lecture. Un préfixe seul ne confine pas les chemins. Aucune vérification cryptographique n’a lieu. La référence doit être résolue dans un jeu de clés maîtrisé.

Travail pratique : Testez kid connu, inconnu, doublon ambigu et chaîne ressemblant à un chemin dans un validateur isolé.

Critères de correction : Refusez les cas non résolus sans lecture arbitraire. Vérifiez le nombre d’accès réseau et l’absence de paramètres privés dans le jeu public.