Passer au contenu principal
L’authentification du client par avec clé privée est une méthode alternative d’authentification du client pour les connexions d’entreprise Connect (OIDC) et Okta Workforce. Alors que l’authentification du client s’effectue le plus souvent en transmettant un partagé, l’authentification du client par JWT avec clé privée transmet plutôt un JWT signé afin d’améliorer la sécurité de l’application. En utilisant cette fonctionnalité, vous pouvez éviter certaines faiblesses de sécurité courantes souvent observées avec 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 à chaque requête.
  • Des mécanismes limités pour appliquer 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 l’authentification du client par JWT avec clé privée pour vos connexions d’entreprise OIDC et Okta Workforce au moyen de 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’une application auprès du ou du fournisseur OpenID. Avec l’authentification du client par JWT avec clé privée, un JWT d’assertion du client signé est transmise au fournisseur OpenID au lieu d’un secret client. Le JWT d’assertion du client contient les revendications suivantes :
  • Un aud () qui identifie le du fournisseur OpenID.
  • Un jti (ID JWT) pour permettre un usage unique ou une protection contre la relecture.
  • Un exp (heure d’expiration) qui limite la période de validité du jeton.
  • Un sub et iss qui identifient l’.
L’authentification du client par JWT avec clé privée offre une méthode d’authentification plus sécurisée, car elle élimine l’utilisation de secrets client partagés. Le JWT est plutôt signé à l’aide de la clé privée de l’application, et le fournisseur OpenID n’a accès qu’à la clé publique.

​
Flux d’authentification du client avec Private Key JWT

Après s’être authentifié auprès d’un (IdP) en amont, l’utilisateur est redirigé vers Auth0 avec un code d’autorisation, qui est échangé contre des jetons au point de terminaison de jeton du fournisseur OpenID. Lorsque Private Key JWT est activé pour une connexion, l’appel au point de terminaison de jeton du fournisseur OpenID utilise une assertion du client au lieu d’un secret client, afin de renforcer la sécurité de l’authentification. Les étapes suivantes présentent un flux d’authentification du client avec Private Key JWT typique.
Schéma du flux d’authentification du client avec Private Key JWT.
Pour effectuer ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce, nouvelle ou existante, avec token_endpoint_auth_method=private_key_jwt, au moyen de l’Auth0 Dashboard ou de la Management API. Pour en savoir plus, consultez la section Configurer l’authentification du client avec 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 current actif, tandis que l’autre est étiqueté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 sur le serveur d’autorisation;
    • copier et coller le jwks_uri dans le serveur d’autorisation.
  3. Un utilisateur effectue une action qui nécessite une authentification, comme 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 des é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 un JWT d’assertion du client et le signe à l’aide de la clé privée current.
  9. Auth0 transmet le JWT d’assertion du client au serveur d’autorisation.
  10. Le serveur d’autorisation repère l’application associée au client_id fourni.
  11. Le serveur d’autorisation récupère les clés publiques depuis Auth0 si un jwks_uri a été fourni; sinon, il identifie la clé publique enregistrée à l’étape 2.
  12. Si le jwks_uri a été demandé, Auth0 renvoie les clés publiques sous forme de 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 du client par JWT avec clé privée

Vous pouvez configurer les connexions d’entreprise OIDC et Okta Workforce pour utiliser l’authentification du client par JWT avec clé privée dans l’Auth0 Dashboard ou au moyen de la Management API. Les étapes pour chaque méthode sont indiquées ci-dessous.
  • Auth0 génère automatiquement une paire de clés de signature privée et publique 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 aucun algorithme n’est précisé.
  • Les JWT signés expirent automatiquement après 60 secondes.

​
Auth0 Dashboard

Vous pouvez utiliser le Auth0 Dashboard pour configurer l’authentification du client par JWT avec clé privée pour les connexions OIDC et Okta Workforce, qu’elles soient nouvelles ou 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, fournissez les détails de votre nouvelle connexion, y compris son nom et l’URL de découverte.
  4. Configurez les champs suivants pour activer l’authentification par JWT avec clé privée :
    • Réglez Communication Channel à Back Channel.
    • Réglez Authentication Method à Private Key JWT.
  5. Sélectionnez Create pour enregistrer votre nouvelle connexion.

​
Management API

Vous pouvez utiliser la Management API pour configurer l’authentification du client par JWT avec clé privée pour les connexions OIDC, nouvelles comme existantes.
Pour créer une nouvelle connexion OIDC qui utilise l’authentification du client par JWT avec clé privée, appelez le point de terminaison Créer une connexion en définissant les propriétés connection.options suivantes de façon appropriée :
PropriétéDescription
typeDéfinissez cette propriété sur back_channel.
token_endpoint_auth_methodMéthode d’authentification utilisée au point de terminaison de jeton du fournisseur d’identité. Définissez-la sur private_key_jwt pour utiliser une assertion JWT signée afin de renforcer la sécurité, ou sur client_secret_post pour envoyer les informations d’identification dans le corps de la requête. La valeur par défaut est client_secret_post. S’applique uniquement aux stratégies oidc et okta.
token_endpoint_auth_signing_algFacultatif. Algorithme utilisé pour signer les assertions du client. Valeurs acceptées : RS256, RS384, RS512, PS256, PS384, ES256, ES384. Si aucune valeur n’est définie, la valeur par défaut est RS256. S’applique uniquement aux stratégies oidc et okta.
id_token_signed_response_algsFacultatif. Liste des algorithmes autorisés pour vérifier les ID tokens émis par le fournisseur d’identité. Lorsqu’elle est définie, Auth0 rejette les ID tokens signés avec un algorithme qui ne figure pas dans cette liste. Valeurs acceptées : RS256, RS384, RS512, PS256, PS384, ES256, ES384. Si elle n’est pas définie, Auth0 accepte les ID tokens signés avec n’importe quel algorithme pris en charge. S’applique uniquement aux stratégies oidc et okta.
token_endpoint_jwtca_aud_formatFacultatif. Spécifie le format de la revendication aud (audience) dans le JWT utilisé pour l’authentification du client au point de terminaison de jeton. Définissez-la sur issuer pour utiliser l’URL de l’émetteur OIDC, ou sur token_endpoint pour utiliser l’URL du point de terminaison de jeton. La valeur par défaut est token_endpoint.
Exemple d’appel POST
POST /api2/connections

{
  strategy: 'oidc',
  options: {
    type: "back_channel",
    token_endpoint_auth_method: "private_key_jwt",
    token_endpoint_auth_signing_alg: "RS256",
    id_token_signed_response_algs: ["RS256", "RS384"]
  },
  …
}

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

Une fois votre connexion configurée pour utiliser l’authentification du client par JWT avec clé privée, vous pouvez récupérer ses clés publiques à partir de l’Auth0 Dashboard, de la Management API ou d’une URI JWKS publique.
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 à son 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, appelez le point de terminaison Get connection keys à l’aide de l’ID de votre connexion.
L’utilisation de ce point de terminaison exige le scope read:connections_keys.
Exemple d’appel GET
GET /api2/connections/{id}/keys
Exemple de réponse
{
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgIJP...Ek=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQcCo...AA==
-----END PKCS7-----
",
    kid: "E4CXqUP6r92yo0f_sdkdC",
    next: true,
    fingerprint: "7F:33:86:D9:4A:98:B2:DC:B0:41:74:54:DA:31:E7:74:42:32:96:8C",
    thumbprint: "7F3386D94A98B2DCB0417454DA31E7744232968C"
  }, 
  {
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgI...Ss=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQ...AA==
-----END PKCS7-----
",
    kid: "_4WuXpXlwwmSE65saKWDM",
    current: true,
    current_since: "2025-01-24T08:50:06.662Z",
    fingerprint: "33:7D:6F:35:46:31:AD:6E:69:43:01:A2:77:DF:8E:73:64:F6:E8:5B",
    thumbprint: "337D6F354631AD6E694301A277DF8E7364F6E85B"
  }, 
  {
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBA...6Q=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcN...AA==
-----END PKCS7-----
",
    kid: "roUD9STeDy9qBTx5XjaTz",
    previous: true,
    current_since: "2025-01-24T08:48:51.523Z",
    current_until: "2025-01-24T08:50:06.663Z",
    fingerprint: "44:D3:DD:3B:63:99:59:9A:39:D9:F4:F0:4F:1B:AC:BB:18:72:40:5C",
    thumbprint: "44D3DD3B6399599A39D9F4F04F1BACBB1872405C"
  }
Certains fournisseurs d’identité permettent de fournir des clés publiques pour private_key_jwt sous la forme d’une URI JWKS publique.Si des clés publiques ont été générées pour une connexion, vous pouvez les récupérer en ajoutant l’URI suivante à la configuration de votre IdP :
https://{domaine Auth0}/oauth/connection/{nom de la connexion}/.well-known/jwks.json
Les URI JWKS sont assujetties aux limites de débit globales. Vous pouvez mettre en cache les clés publiques pour éviter d’atteindre ces limites. Comme bonne pratique, Auth0 recommande une durée de mise en cache d’au moins 5 à 10 minutes afin d’éviter d’appeler le point de terminaison de l’URI JWKS à chaque tentative de connexion.

​
Rotation des clés de signature

L’authentification du client par JWT avec clé privée prend en charge la rotation des clés de signature afin d’offrir une sécurité accrue par rapport au caractère statique et à la longue durée de vie des secrets client partagés. La rotation des clés de signature renforce la sécurité en limitant la durée d’exposition d’une même clé, ce qui réduit la fenêtre pendant laquelle un attaquant pourrait 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 la rotation des clés de signature au bout d’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 Okta Workforce, sélectionnez Browse.
  3. Choisissez la connexion appropriée, puis ouvrez 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, tout JWT en cours signé avec la clé précédente devient immédiatement invalide et sa vérification peut échouer auprès de votre IdP.
Pour consulter les clés publiques au moyen de la Management API, appelez le point de terminaison Rotate Connection Signing Keys à l’aide de l’ID de votre connexion.
L’utilisation de ce point de terminaison nécessite les scopes create:connections_keys et update:connections_keys.
POST /v2/connections/{id}/keys/rotate
Après la rotation, tout JWT en cours signé avec la clé précédente devient immédiatement invalide et sa vérification peut échouer auprès de votre IdP.

Comprendre la rotation des clés

Dans votre connexion OIDC ou Okta Workforce, vos clés de signature se voient attribuer l’un des états suivants :
  • Actuelle : la clé de signature actuellement utilisée pour l’application.
  • Suivante : la prochaine clé de signature qui sera utilisée pour l’application une fois la clé actuelle révoquée.
  • Précédente : une clé de signature expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque l’authentification du client par JWT avec clé privée est activée 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 supprimée 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 l’état previous.
  3. La clé next devient la clé active et reçoit l’état current. Désormais, les JWT d’assertion du client 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 de la rotation. La nouvelle clé de signature reçoit l’état next.

​
En savoir plus