Skip to main content
Le JSON Web Key Set (JWKS) est un ensemble de clés contenant les clés publiques utilisées pour vérifier tout émis par le et signé à l’aide de l’algorithme de signature RS256. Lors de la création d’applications et d’API dans Auth0, deux algorithmes sont pris en charge pour signer les  : RS256 et HS256. RS256 génère une signature asymétrique, ce qui signifie qu’une clé privée doit être utilisée pour signer le JWT et qu’une autre clé publique doit être utilisée pour vérifier la signature. Auth0 utilise la spécification JSON Web Key (JWK) pour représenter les clés cryptographiques utilisées pour signer les jetons RS256. Cette spécification définit deux structures de données de haut niveau : JSON Web Key (JWK) et JSON Web Key Set (JWKS). Voici les définitions tirées de la spécification : Auth0 expose un endpoint JWKS pour chaque tenant, situé à https://{yourDomain}/.well-known/jwks.json. Cet endpoint contient le JWK utilisé pour vérifier tous les JWT émis par Auth0 pour ce tenant.
Actuellement, Auth0 signe avec un seul JWK à la fois; toutefois, il est important de supposer que cet endpoint pourrait contenir plusieurs JWK. Par exemple, plusieurs clés peuvent se trouver dans le JWKS lors de la rotation des clés de signature d’application.

​
Mettre en cache le JSON Web Key Set

Nous vous recommandons de mettre en cache le JWKS récupéré par votre application depuis le point de terminaison JWKS, car cela permet de :
  • Ne pas épuiser les limites de débit de votre tenant avec des requêtes répétées.
  • Améliorer les performances en évitant d’effectuer une requête réseau vers le point de terminaison JWKS à chaque validation de jeton.
  • Améliorer la résilience afin que votre application puisse continuer à valider les jetons si le point de terminaison JWKS est brièvement indisponible.
Vous pouvez utiliser une bibliothèque JWKS ou le middleware de votre framework pour gérer la mise en cache, y compris la récupération du JWKS lorsqu’un kid est inconnu et la limitation de la fréquence de ces récupérations. Par exemple, nos Quickstarts utilisent des bibliothèques qui s’en chargent pour vous. Pour éviter la charge liée au développement et à la maintenance, nous vous déconseillons d’implémenter vous-même la mise en cache. Toutefois, si votre cas d’utilisation l’exige, vous pouvez suivre ces directives :
  • Mettez le JWKS en cache pendant 5 à 10 minutes afin d’éviter de le récupérer à chaque requête. Des intervalles plus longs réduisent davantage le nombre de requêtes et la latence.
  • Lorsque vous effectuez la rotation des clés de signature, Auth0 signe les nouveaux jetons avec la nouvelle clé. Si vous recevez un jeton dont l’ID de clé (kid) ne figure pas dans votre JWKS mis en cache, invalidez le cache et récupérez à nouveau le JWKS afin d’obtenir la nouvelle clé. L’actualisation lors de la réception d’un kid inconnu, plutôt qu’à l’expiration du cache, permet à votre application de prendre rapidement en compte les clés ayant fait l’objet d’une rotation. Ainsi, un intervalle de mise en cache plus long ne retarde pas la rotation.
  • Limitez la fréquence des nouvelles récupérations en cas d’absence dans le cache (par exemple, ne réessayez qu’une seule fois) afin qu’un lot de jetons signés avec des clés inconnues ne puisse pas déclencher un flot de requêtes vers le point de terminaison JWKS et épuiser vos limites de débit. Définissez votre intervalle de mise en cache selon la rapidité avec laquelle vous devez cesser d’accepter les jetons signés avec une clé révoquée manuellement.

​
En savoir plus