Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://auth0-fix-auth-api-docs-migration-completion.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Clé privée L’authentification du client est une méthode de remplacement de l’authentification du client pour le Connect (OIDC) et les connexions d’entreprise Okta Workforce. L’authentification client s’effectue généralement en transmettant un secret client. L’authentification client JWT avec clé privée transmet quant à elle un JWT signé afin de renforcer la sécurité de l’application. En utilisant cette fonctionnalité, vous pouvez éviter certaines failles de sécurité courantes souvent associées à l’authentification standard par clé secrète, telles que :
  • Un risque accru d’interception et de réutilisation, car les informations confidentielles du client doivent être transmises entre les parties à chaque requête.
  • Les mécanismes permettant d’imposer l’expiration et d’empêcher la réutilisation par des acteurs malveillants sont limités.
  • Un risque accru de fuites ou de divulgation, les deux parties conservant le secret client.
Vous pouvez configurer l’authentification client JWT avec clé privée pour vos connexions OIDC et Okta Workforce Entreprise via ou .

​
Le fonctionnement

Le flux de connexion OIDC utilise des points de terminaison authentifiés, tels que /oauth/token ou /oauth/par, pour vérifier l’identité d’un client auprès du ou fournisseur OpenID. Avec l’authentification client JWT avec clé privée, un JWT d’assertion client signé est transmis au fournisseur OpenID à la place d’un secret client. Le JWT d’assertion client contient les demandes suivantes :
  • Un aud () déterminer le public .
  • Un jti (JWT d’ID) permettant une utilisation unique ou une protection contre la relecture.
  • Une valeur exp (durée d’expiration) qui limite la période de validité du jeton.
  • Une sub et iss déterminant l’.
L’authentification JWT avec clé privée offre une méthode d’authentification plus sécurisée en supprimant l’utilisation de secrets client partagés. À la place, le JWT est 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 JWT avec clé privée

Une fois qu’un utilisateur s’est authentifié auprès d’un (IdP), l’utilisateur est redirigé vers Auth0 avec un code d’autorisation qui est échangé contre des jetons au niveau du point de terminaison de jetons du fournisseur OpenID. Lorsque l’option « JWT avec clé privée » est activée pour une connexion, l’appel vers le point de terminaison de jetons du fournisseur OpenID utilise une assertion client plutôt qu’un secret client, afin de garantir une sécurité accrue lors de l’authentification. Les étapes suivantes illustrent un processus type d’authentification client JWT avec clé privée.
Schéma illustrant le flux d’authentification client JWT avec clé privée.
Pour terminer ce flux, vous devez d’abord configurer une connexion OIDC ou Okta Workforce (nouvelle ou existante) avec token_endpoint_auth_method=private_key_jwt via Auth0 Dashboard ou Management API. Pour en savoir plus, consulter la section Configurer l’authentification client JWT avec clé privée.
  1. Après avoir configuré votre connexion, Auth0 génère et stocke automatiquement deux paires de clés, une publique et une privée.
    • Une paire de clés correspond à l’ensemble current actif, tandis que l’autre ensemble est désigné par next afin de permettre 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 :
    • Copiez-collez le jwks_uri sur le serveur d’autorisation.
  3. Un utilisateur effectue une action qui nécessite une authentification, comme la connexion à votre application.
  4. Auth0 envoie une requête au serveur d’autorisation pour lancer l’authentification.
  5. Le serveur d’autorisation affiche les écrans d’authentification et de consentement à l’utilisateur.
  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 client et le signe à l’aide de la clé privée current.
  9. Auth0 transmet le JWT d’assertion client au serveur d’autorisation.
  10. Le serveur d’autorisation recherche le client à partir de l’client_id fourni.
  11. Le serveur d’autorisation récupère les clés publiques auprès d’Auth0 si un jwks_uri a été fourni; dans le cas contraire, le serveur détermine la clé publique enregistrée à la deuxième étape.
  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 nécessaire à l’exécution du flux.

​
Configurer l’authentification client JWT avec clé privée

Vous pouvez configurer les connexions OIDC et Okta Workforce Entreprise pour utiliser l’authentification client JWT avec clé privée via Auth0 Dashboard ou Management API. Vous trouverez ci-dessous les étapes à suivre pour chaque méthode.
*Les paires de clés de connexion 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 Okta et OIDC Entreprise. Si aucun algorithme n’est défini, RS256 est utilisé. *Les JWT signés expirent automatiquement au bout de 60 secondes.

​
Auth0 Dashboard

Vous pouvez utiliser Auth0 Dashboard pour configurer l’authentification client JWT par clé privée pour les connexions OIDC et Okta Workforce, que ce soit pour les nouvelles connexions ou celles existantes.
  1. Dans Auth0 Dashboard, accédez à Authentification > Entreprise.
  2. En regard de OpenID Connect ou Okta Workforce, sélectionnez Créer.
  3. Dans la section Général, indiquez les détails de votre nouvelle connexion, notamment son nom et son URL de découverte.
  4. Configurez les champs suivants pour activer le JWT avec clé privée : *Réglez le canal de communication sur canal d’appui. *Définissez la méthode d’authentification sur JWT avec clé privée.
  5. Sélectionnez Créer pour enregistrer votre nouvelle connexion.
  6. Sur la fenêtre de confirmation, sélectionnez Modifier pour appliquer vos modifications.

​
Management API

Vous pouvez utiliser Management API pour configurer l’authentification client JWT par clé privée pour les connexions OIDC, que ce soit pour les nouvelles connexions ou celles existantes.
Pour créer une nouvelle connexion OIDC utilisant l’authentification client JWT avec clé privée, appelez le point de terminaison Créer une connexion en configurant correctement les propriétés connection.options suivantes :
PropriétéDescription
typeDéfinir cette propriété sur back_channel.
token_endpoint_auth_methodMéthode d’authentification utilisée au point de terminaison du jeton du fournisseur d’identité. Définissez la valeur 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 identifiants dans le corps de la requête. Par défaut, token-endpoint. S’applique uniquement aux stratégies oidc et okta.
token_endpoint_auth_signing_algFacultatif. Algorithme utilisé pour signer les assertions client. Valeurs acceptées : RS256, RS384, RS512, PS256, PS384, ES256, ES384. Si aucun algorithme n’est défini, RS256 est utilisé. S’applique uniquement aux stratégies oidc et okta.
id_token_signed_response_algsFacultatif. Liste des algorithmes autorisés pour la vérification des jetons d’ID émis par le fournisseur d’identité. Une fois cette option activée, Auth0 rejette les jetons d’ID signés à l’aide d’un algorithme ne figurant pas dans cette liste. Valeurs acceptées : RS256, RS384, RS512, PS256, PS384, ES256, ES384. Si cette valeur n’est pas définie, Auth0 accepte les jetons d’ID signés à l’aide de n’importe quel algorithme pris en charge. S’applique uniquement aux stratégies oidc et okta.
token_endpoint_jwtca_aud_formatFacultatif. Indique le format de l’attribut aud (public) dans le JWT utilisé pour l’authentification client au niveau du point de terminaison du jeton. Définissez la valeur sur issuer pour utiliser l’URL de l’émetteur OIDC, ou sur token_endpoint pour utiliser l’URL du point de terminaison du jeton.
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ération des clés de connexion

Une fois que votre connexion a été configurée pour utiliser l’authentification client JWT avec clé privée, vous pouvez récupérer ses clés publiques via Auth0 Dashboard, Management API ou un URI JWKS public.
Pour récupérer les clés de connexion via Auth0 Dashboard :
  1. Rendez-vous à Authentification > Entreprise.
  2. En regard de OpenID Connect ou Okta Workforce, sélectionnez Parcourir.
  3. Choisissez la connexion souhaitée. Accédez ensuite à son onglet Identifiants.
  4. Recherchez la section Identifiants et cliquez sur l’icône Télécharger située à côté de la clé de connexion correspondante.
Pour consulter les clés publiques via Management API, appelez le point de terminaison Obtenir les clés de connexion en utilisant l’identifiant de votre connexion.
L’utilisation de ce point de terminaison nécessite la permission 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é autorisent la fourniture des 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 fournisseur d’identité (IdP) :
https://{auth0 domain}/oauth/connection/{connection name}/.well-known/jwks.json
Les URI JWKS sont pris en compte dans les limites anti-attaques. Vous pouvez utiliser la mise en cache des clés publiques pour éviter d’atteindre ces limites. Autho0 recommande, à titre de pratique exemplaire, un intervalle de mise en cache d’au moins cinq à dix minutes afin d’éviter d’appeler le point de terminaison URI JWKS à chaque tentative de connexion.

​
Rotation des clés d’authentification

L’authentification client JWT avec clé privée prend en charge la rotation des clés de connexion, ce qui renforce la sécurité par rapport à la nature statique et durable des secrets clients partagés. La rotation des clés de connexion renforce la sécurité en limitant la durée d’exposition de chaque clé, réduisant ainsi les possibilités qu’un pirate informatique parvienne à les compromettre. Cela permet également d’intervenir rapidement en cas d’incident de sécurité. Pour éviter toute interruption, Auth0 recommande de renouveler les clés de connexion tous les ans Vous pouvez utiliser Auth0 Dashboard ou Management API pour renouveler les clés de connexion :
Pour effectuer une rotation de vos clés de connexion via Auth0 Dashboard :
  1. Rendez-vous à Authentification > Entreprise.
  2. En regard de OpenID Connect ou Okta Workforce, sélectionnez Parcourir.
  3. Choisissez la connexion souhaitée. Accédez ensuite à son onglet Identifiants.
  4. Dans la section Identifiants, sélectionnez Rotation des clés.
  5. Dans la fenêtre contextuelle, sélectionnez Enregistrer pour confirmer la rotation.
Une fois la rotation effectuée, tous les JWT en cours de validité signés avec la clé précédente deviennent immédiatement inactifs et risquent de ne pas passer la vérification auprès de votre fournisseur d’identité (IdP).
Pour consulter les clés publiques via Management API, appelez le point de terminaison Rotation des clés de connexion en utilisant l’identifiant de votre connexion.
L’utilisation de ce point de terminaison nécessite les permissions create:connections_keys et update:connections_keys.
POST /v2/connections/{id}/keys/rotate
Une fois la rotation effectuée, tous les JWT en cours de validité signés avec la clé précédente deviennent immédiatement inactifs et risquent de ne pas passer la vérification auprès de votre fournisseur d’identité (IdP).

Understanding key rotation

Dans votre connexion OIDC ou Okta Workforce, vos clés de connexion se voient attribuer l’un des états suivants :
  • Clé actuelle: La clé de connexion actuellement utilisée pour l’application.
  • Clé suivante : La clé de connexion suivante à utiliser pour l’application une fois que la clé actuelle aura été révoquée.
  • Clé précédente : Une clé de connexion expirée ou autrement révoquée qui n’est plus utilisée.
Lorsque l’authentification client 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 previous qu’après la rotation.Lors de la rotation des clés de connexion, les changements suivants se produisent :
  1. La clé current est supprimée et révoquée ; tout JWT signé avec cette clé échouera à la vérification auprès du fournisseur d’identité (IdP) si celui-ci a été configuré avec la clé jwks_uri.
  2. La clé current se voit attribuer l’état previous.
  3. La clé next devient la touche active et se voit attribuer l’état current. Dorénavant, les JWT d’authentification client seront signés à l’aide de cette clé.
  4. Une nouvelle clé de connexion est générée automatiquement pour remplacer la clé qui a fait l’objet d’une rotation. La nouvelle clé de connexion a l’état next.

​
En apprendre plus