Skip to main content
Private Key Client Authentication est une méthode d’authentification du client alternative pour les connexions d’entreprise Connect (OIDC) et Okta Workforce. Alors que l’authentification du client se fait le plus souvent au moyen d’un partagé, Private Key JWT Client Authentication utilise plutôt un JWT signé afin de renforcer la sécurité de l’application. En utilisant cette fonctionnalité, vous pouvez éviter certaines faiblesses de sécurité courantes souvent associées à l’authentification standard par secret client, notamment :
  • Un risque accru d’interception et de réutilisation, puisque les secrets client doivent être transmis entre les parties pour chaque requête.
  • Des mécanismes limités pour imposer une date d’expiration et empêcher la réutilisation par des acteurs malveillants.
  • Un risque accru de fuite ou d’exposition, puisque les deux parties détiennent le secret client.
Vous pouvez configurer Private Key JWT Client Authentication pour vos connexions d’entreprise OIDC et Okta Workforce au moyen du ou de la .

​
Fonctionnement

Le flux de connexion OIDC utilise des points de terminaison authentifiés comme /oauth/token ou /oauth/par pour vérifier l’identité d’un client auprès du ou du fournisseur OpenID. Avec Private Key JWT Client Authentication, une assertion JWT client signée est transmise au fournisseur OpenID au lieu d’un secret client. L’assertion JWT client contient les claims suivants :
  • Un aud () qui identifie l’ du fournisseur OpenID.
  • Un jti (ID JWT) pour permettre un usage unique ou une protection contre les attaques par rejeu.
  • Un exp (heure d’expiration) qui limite la période de validité du jeton.
  • Un sub et un iss qui identifient le .
Private Key JWT Client Authentication offre une méthode d’authentification plus sécurisée en éliminant l’utilisation de secrets client partagés. Le JWT est plutôt signé à l’aide de la clé privée du client, et le fournisseur OpenID n’a accès qu’à la clé publique.

​
Flux d’authentification client Private Key JWT

Une fois que l’utilisateur a terminé son authentification auprès d’un (IdP) en amont, il est redirigé vers Auth0 avec un code d’autorisation, qui est ensuite échangé contre des jetons au point de terminaison de jeton du fournisseur OpenID. Lorsque Private Key JWT est activé pour une connexion, la requête au point de terminaison de jeton du fournisseur OpenID utilise une assertion client plutôt qu’un secret client, pour une authentification plus sécurisée. Les étapes suivantes illustrent un flux d’authentification client Private Key JWT typique.
Schéma du flux d’authentification client Private Key JWT.
Pour suivre ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce, nouvelle ou existante, avec token_endpoint_auth_method=private_key_jwt, soit dans votre Auth0 Dashboard, soit au moyen de la Management API. Pour en savoir plus, consultez la section Configurer l’authentification client Private Key JWT.
  1. Après avoir configuré votre connexion, Auth0 génère et stocke automatiquement deux paires de clés publiques et privées.
    • Une paire de clés correspond à l’ensemble actif current, tandis que l’autre est libellée next pour prendre en charge la rotation des clés.
  2. Selon votre IdP, vous devez ensuite soit :
    • Télécharger la clé publique current et téléverser le fichier vers le serveur d’autorisation, ou :
    • Copier et coller le jwks_uri dans le serveur d’autorisation.
  3. Un utilisateur effectue une action qui nécessite une authentification, par exemple se connecter à votre application.
  4. Auth0 envoie une requête au serveur d’autorisation pour lancer l’authentification.
  5. Le serveur d’autorisation affiche à l’utilisateur les écrans d’authentification et de consentement.
  6. L’utilisateur s’authentifie et donne son consentement au serveur d’autorisation.
  7. Le serveur d’autorisation envoie un code d’autorisation à Auth0.
  8. Auth0 génère une assertion client JWT et la signe à l’aide de la clé privée current.
  9. Auth0 transmet l’assertion client JWT au serveur d’autorisation.
  10. Le serveur d’autorisation recherche le client à partir du client_id fourni.
  11. Le serveur d’autorisation récupère les clés publiques à partir d’Auth0 si un jwks_uri a été fourni; sinon, il repère la clé publique enregistrée à l’étape 2.
  12. Si le jwks_uri a été demandé, Auth0 renvoie les clés publiques au format JWKS.
  13. Le serveur d’autorisation valide le JWT en vérifiant la signature à l’aide de la clé publique current, identifiée par kid dans l’en-tête du JWT client_assertion.
  14. Le serveur d’autorisation génère un jeton d’accès.
  15. Le serveur d’autorisation transmet le jeton d’accès à Auth0.
  16. À l’aide du jeton d’accès, Auth0 demande une ressource au serveur de ressources.
  17. Le serveur de ressources fournit la ressource pour terminer le flux.

​
Configurer l’authentification client par Private Key JWT

Vous pouvez configurer les connexions d’entreprise OIDC et Okta Workforce pour utiliser l’authentification client par Private Key JWT à l’aide de l’Auth0 Dashboard ou de la Management API. Les étapes de chaque méthode sont fournies ci-dessous.
  • Les paires de clés de signature privées et publiques sont générées automatiquement par Auth0 pour chaque connexion.
  • Vous pouvez utiliser les algorithmes suivants pour signer les JWT d’assertion client : RS256, RS384, RS512, PS256, PS384, ES256 et ES384 pour les connexions d’entreprise Okta et OIDC. La valeur par défaut est RS256 si elle n’est pas précisée.
  • Les JWT signés expirent automatiquement après 60 secondes.

​
Auth0 Dashboard

Vous pouvez utiliser le Auth0 Dashboard pour configurer la méthode d’authentification du client Private Key JWT pour les nouvelles connexions OIDC et Okta Workforce ainsi que pour les connexions existantes.
  1. Dans votre Auth0 Dashboard, accédez à Authentication > Enterprise.
  2. À côté de OpenID Connect ou de Okta Workforce, sélectionnez Create.
  3. Dans la section General, indiquez les détails de votre nouvelle connexion, y compris son nom et son URL de découverte.
  4. Configurez les champs suivants pour activer Private Key JWT :
    • Réglez Communication Channel sur Back Channel.
    • Réglez Authentication Method sur Private Key JWT.
  5. Sélectionnez Create pour enregistrer votre nouvelle connexion.

​
Management API

Vous pouvez utiliser la Management API pour configurer Private Key JWT Client Authentication pour les connexions OIDC, qu’elles soient nouvelles ou existantes.
Pour créer une nouvelle connexion OIDC qui utilise Private Key JWT Client Authentication, appelez le point de terminaison Create a Connection avec les propriétés connection.options suivantes définies de façon appropriée :Exemple de requête POST

​
Récupérer les clés de signature

Une fois votre connexion configurée pour utiliser Private Key JWT Client Authentication, vous pouvez récupérer ses clés publiques à partir de l’Auth0 Dashboard, de la Management API ou d’un URI JWKS public.
Pour récupérer les clés de signature dans l’Auth0 Dashboard :
  1. Accédez à Authentication > Enterprise.
  2. À côté de OpenID Connect ou Okta Workforce, sélectionnez Browse.
  3. Choisissez la connexion appropriée, puis accédez à l’onglet Credentials.
  4. Repérez la section Credentials et sélectionnez l’icône Download à côté de la clé de signature appropriée.
Pour afficher les clés publiques au moyen de la Management API, envoyez une requête au point de terminaison Get connection keys à l’aide de l’ID de votre connexion.
L’utilisation de ce point de terminaison nécessite le scope read:connections_keys.
Exemple de requête GET
Exemple de réponse
Certains fournisseurs d’identité permettent de fournir les clés publiques pour private_key_jwt sous la forme d’un URI JWKS (JSON Web Key Set) public.Si des clés publiques ont été générées pour une connexion, vous pouvez les récupérer en ajoutant l’URI suivant à la configuration de votre IdP :
Les URI JWKS sont pris en compte dans les limites de débit globales. Vous pouvez mettre les clés publiques en cache pour éviter d’atteindre ces limites. Comme bonne pratique, Auth0 recommande un intervalle de cache d’au moins 5 à 10 minutes afin d’éviter d’appeler le point de terminaison URI JWKS à chaque tentative de connexion.

​
Rotation des clés de signature

Private Key JWT Client Authentication prend en charge la rotation des clés de signature, ce qui offre une sécurité accrue par rapport au caractère statique et durable des secrets client partagés. La rotation des clés de signature améliore la sécurité en limitant le temps d’exposition de chaque clé, ce qui réduit la fenêtre d’opportunité pour un attaquant de la compromettre. Elle permet aussi de réagir rapidement à la suite d’un incident de sécurité. Pour éviter toute interruption, Auth0 recommande d’effectuer une rotation des clés de signature après un an. Vous pouvez utiliser soit l’Auth0 Dashboard, soit la Management API pour effectuer la rotation des clés de signature :
Pour effectuer la rotation de vos clés de signature dans l’Auth0 Dashboard :
  1. Accédez à Authentication > Enterprise.
  2. À côté de OpenID Connect ou de Okta Workforce, sélectionnez Browse.
  3. Choisissez la connexion appropriée, puis accédez à son onglet Credentials.
  4. Dans la section Credentials, sélectionnez Rotate Keys.
  5. Dans la fenêtre contextuelle, sélectionnez Save pour confirmer la rotation.
Après la rotation, tous les JWT en cours signés avec la clé précédente deviennent immédiatement inactifs et leur vérification auprès de votre IdP peut échouer.
Pour afficher les clés publiques au moyen de la Management API, envoyez une requête au point de terminaison Rotate Connection Signing Keys en utilisant l’ID de votre connexion.
L’utilisation de ce point de terminaison exige à la fois les scopes create:connections_keys et update:connections_keys.
Après la rotation, tous les JWT en cours signés avec la clé précédente deviennent immédiatement inactifs et leur vérification auprès de votre IdP peut échouer.

Comprendre la rotation des clés

Dans votre connexion OIDC ou Okta Workforce, vos clés de signature se voient attribuer l’un des statuts suivants :
  • Current : la clé de signature actuellement utilisée pour l’application.
  • Next : la prochaine clé de signature à utiliser pour l’application une fois la clé actuelle révoquée.
  • Previous : une clé de signature expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque Private Key JWT Client Authentication est activé pour la première fois pour une connexion, seule une paire de clés current et next est générée. Une clé n’est marquée comme previous qu’après une rotation.Lors de la rotation des clés de signature, les changements suivants se produisent :
  1. La clé current est retirée de l’utilisation et révoquée, et tout JWT signé avec cette clé échouera à la vérification auprès de l’IdP si l’IdP a été configuré avec le jwks_uri.
  2. La clé current se voit attribuer le statut previous.
  3. La clé next devient la clé active et se voit attribuer le statut current. Dorénavant, les client assertion JWT seront signés avec cette clé.
  4. Une nouvelle clé de signature est automatiquement générée pour remplacer la clé ayant fait l’objet d’une rotation. La nouvelle clé de signature a le statut next.

​
En savoir plus