Configurer les connexions Enterprise avec Demonstrating Proof-of-Possession (DPoP)

Découvrez comment sécuriser les connexions d’entreprise OIDC et Okta au moyen d’une liaison cryptographique des jetons.

Demonstrating Proof-of-Possession (DPoP) est une extension du framework OAuth 2.0. Pour en savoir plus sur le protocole DPoP et sur la façon dont il sert à associer cryptographiquement les jetons à l’émetteur, consultez Demonstrating Proof-of-Possession (DPoP). Si vous utilisez Okta ou OpenID Connect (OIDC) comme fournisseur d’identité (IdP) et que vous les avez configurés comme connexion d’entreprise dans Auth0, vous pouvez activer et configurer DPoP afin de lier les jetons d’accès de votre IdP à des clés cryptographiques. L’utilisation de DPoP empêche les attaques par rejeu de jetons et aide à répondre aux exigences de conformité, comme Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) OIDC Security Level 1 ou Financial-grade API (FAPI) 2.0.

Avant de commencer

Avant d’activer DPoP dans Auth0 :

• Votre fournisseur d’identité en amont doit prendre en charge DPoP conformément à la spécification RFC-9449.
• Vous devez déjà disposer d’une connexion d’entreprise OIDC ou Okta, ou être en mesure d’en créer une. Pour savoir comment créer une connexion d’entreprise dans Auth0, consultez Enterprise Connections.
• La connexion ne doit pas être configurée pour utiliser Token Vault.
• La connexion devrait utiliser le flux flux de code d’autorisation + PKCE, avec la clé de preuve pour l’échange de code (PKCE), si votre fournisseur d’identité en amont prend en charge PKCE.
• La connexion doit être de type back_channel.

​

Vérifier la prise en charge par l’IdP en amont

Examinez le document de découverte OIDC de votre IdP pour vérifier la prise en charge de DPoP :

curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration

Dans la réponse, recherchez la valeur DPoP prise en charge dpop_signing_alg_values_supported.

Exemple

{
  "dpop_signing_alg_values_supported": ["ES256", "ES384", "Ed25519", "ES512", "RS256"] 
},

​

Choisissez un algorithme de signature

Avant de configurer DPoP, choisissez un algorithme de signature pris en charge parmi les options suivantes :

Algorithme	Description	Quand l’utiliser
ES256	ECDSA avec la courbe P-256 et SHA-256	Votre fournisseur d’identité prend en charge ES256.
ES384	ECDSA avec la courbe P-384 et SHA-384	Votre fournisseur d’identité exige ES384.
ES512	ECDSA avec la courbe P-521 et SHA-512	Votre fournisseur d’identité exige ES512.
Ed25519	EdDSA avec Curve25519	Votre fournisseur d’identité exige Ed25519 pour des raisons de conformité.

Choisissez ES256, sauf si votre fournisseur d’identité exige expressément un autre algorithme.

​

Activer DPoP

Pour activer DPoP et choisir un algorithme, utilisez Auth0 Dashboard ou la Management API.

Auth0 Dashboard

Dans Auth0 Dashboard :

1. Accédez à Authentication > Enterprise. Sélectionnez la connexion que vous souhaitez configurer.
2. Sélectionnez l’onglet Credentials.
3. Cochez la case Enable Demonstrating Proof of Possession (DPoP).
4. Dans le menu sous Signing Algorithms for DPoP, choisissez votre algorithme.
   
5. Sélectionnez Save.

Management API

Pour utiliser la Management API, vous devez obtenir un jeton d’accès à la Management API.

Effectuez une requête PATCH vers le point de terminaison Update a connection avec dpop_signing_alg_values_supported dans l’objet options :

PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "options": {
    "dpop_signing_alg": "ES256"
  }
}

Si vous appliquez PATCH au paramètre options, l’objet options est remplacé en entier. Pour éviter les données partielles ou d’autres problèmes, assurez-vous que toutes les propriétés voulues sont présentes lorsque vous appliquez PATCH à options.

Remplacez les valeurs de l’espace réservé :

• YOUR_DOMAIN: Le domaine de votre tenant Auth0. Exemple : travel0.us.auth0.com.
• YOUR_CONNECTION_ID: L’ID de votre connexion Enterprise OIDC ou Okta.
• YOUR_MANAGEMENT_API_TOKEN: Un jeton de la Management API avec le scope update:connections

​

Tester DPoP

Après avoir activé DPoP, testez la configuration en lançant un flux de connexion :

1. Accédez à votre application.
2. Démarrez le flux de connexion à l’aide de votre connexion d’entreprise configurée.
3. Terminez la connexion avec votre fournisseur d’identité externe.
4. Consultez les logs Auth0 dans Auth0 Dashboard > Monitoring > Logs pour confirmer.

Une transaction réussie dans une entrée de log devrait ressembler à ceci :

{
  "type": "s",
  "description": "Success Login",
  "details": {
    "dpop_signing_alg": "ES256",
    "idp_token_type": "dpop",
    "upstream_userinfo_fetch": {
      "status": "SUCCESS",
      "dpop_bound": true
    }
   }
}

Les valeurs dpop_signing_alg et idp_token_type: "dpop" confirment qu’Auth0 a envoyé une preuve DPoP à l’aide de l’algorithme configuré et que votre IdP a émis des jetons liés à DPoP. L’objet upstream_userinfo_fetch n’est présent que si le point de terminaison Renseignements sur l’utilisateur est appelé. Le champ dpop_bound n’est présent que si la requête GET vers le point de terminaison /userinfo est correctement liée à DPoP.

​

Désactiver DPoP

Vous pouvez désactiver DPoP à l’aide de l’Auth0 Dashboard ou de la Management API.

Auth0 Dashboard

1. Accédez à Authentication > Enterprise. Sélectionnez la connexion que vous souhaitez configurer.
2. Sélectionnez l’onglet Credentials.
3. Décochez la case Enable Demonstrating Proof of Possession (DPoP).
4. Sélectionnez Enregistrer.

Management API

Pour désactiver DPoP, supprimez la propriété dpop_signing_alg de la configuration de votre connexion :

PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "options": {

  }
}

Si vous appliquez un PATCH au paramètre options, l’objet options est entièrement remplacé. Pour éviter les données partielles ou d’autres problèmes, assurez-vous que toutes les propriétés souhaitées sont présentes lorsque vous appliquez un PATCH à options.

​

Dépannage

Les recommandations suivantes vous aideront à diagnostiquer et à résoudre les problèmes de configuration DPoP pour OIDC et les connexions d’entreprise Okta.

​

Vérifier la configuration Auth0

Avant de commencer le dépannage, vérifiez votre configuration DPoP dans Auth0 :

1. Accédez à Auth0 Dashboard > Authentication > Enterprise.
2. Sélectionnez votre connexion Okta ou OIDC.
3. Vérifiez que la connexion n’est pas configurée avec Token Vault en accédant à Advanced Settings > Grant Types. Assurez-vous que Token Vault n’est pas sélectionné.
4. Utilisez le point de terminaison Update a connection du Management API pour vérifier le paramètre dpop_signing_alg :

GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

Dans la réponse dpop_signing_alg, vérifiez les éléments suivants :

• Vérifiez que l’algorithme fait partie des valeurs prises en charge : ES256, ES384, ES512 ou Ed25519.
• Vérifiez que la connexion utilise l’échange de jetons par back-channel au moyen du Flux de code d’autorisation + PKCE. DPoP n’est pas pris en charge pour les communications en front-channel, comme dans le Flux implicite, et est désactivé sans avertissement lorsque la connexion utilise le front-channel.

​

Champs DPoP manquants dans les logs du tenant

Si les logs de réussite (s) ou d’échec (f) d’Auth0 pour la connexion d’entreprise ne contiennent pas les champs dpop_signing_alg ou idp_token_type, cela peut être dû à l’une des causes suivantes :

• DPoP n’est pas configuré. Vérifiez que dpop_signing_alg est défini dans l’objet options de la connexion à l’aide du point de terminaison Update a connection de la Management API, comme décrit ci-dessus.
• Algorithme non pris en charge. Auth0 prend en charge ES256, ES384, ES512 et Ed25519. Si dpop_signing_alg est défini sur une valeur non prise en charge (par exemple, RS256), DPoP est désactivé en silence. Aucune erreur n’est consignée. Mettez à jour la connexion pour utiliser ES256, ES384, ES512 ou Ed25519.
• Connexion front-channel. DPoP exige un type de connexion d’échange de jeton back_channel. Vous devrez peut-être mettre à jour le grant type vers un flux back-channel comme Authorization Code Flow ou flux de code d’autorisation + PKCE.

​

L’authentification échoue après l’activation de DPoP

Consultez les techniques de dépannage suivantes si vos utilisateurs ne parviennent pas à s’authentifier après avoir activé DPoP sur votre connexion d’entreprise Okta ou OIDC.

Les journaux du tenant devraient afficher un événement d’échec (f) avec dpop_signing_alg, semblable à :

{
  "type": "f",
  "description": "Failed Login",
  "details": {
    "error": "dpop_signing_alg"
  }
}

Notez que l’échec n’inclut pas idp_token_type, car Auth0 n’a pas reçu de token de votre IdP.

​

Le fournisseur d’identité rejette la preuve DPoP

L’IdP peut rejeter explicitement la preuve DPoP qu’Auth0 envoie pendant l’échange de jetons. L’IdP peut renvoyer une erreur invalid_dpop_proof, ce qui entraîne l’échec de l’authentification.

Vérifiez que l’IdP prend en charge DPoP et que l’algorithme configuré (ES256, ES384, ES512 ou Ed25519) figure parmi les algorithmes pris en charge. Vous pouvez le confirmer en consultant le document de découverte OpenID Connect de l’IdP :

curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration

Dans la réponse de l’IdP, recherchez dpop_signing_alg_values_supported. Si ce champ est absent, il se peut que l’IdP ne prenne pas en charge DPoP. Si le champ ne répertorie que des algorithmes qu’Auth0 ne prend pas en charge (par exemple, uniquement RS256), DPoP ne peut pas être utilisé avec cette connexion. Vous devriez désactiver DPoP pour cette connexion ou communiquer avec votre IdP pour activer la prise en charge d’ES256, d’ES384, d’ES512 ou d’Ed25519.

​

L’échange de jetons échoue pour une raison autre que DPoP

Si vous trouvez un log d’échec où dpop_signing_alg est présent, cela ne veut pas nécessairement dire que DPoP est à l’origine de l’échec. Auth0 ajoute des métadonnées DPoP à tous les logs d’échec lorsque DPoP est configuré, même si la cause sous-jacente n’a rien à voir avec DPoP. Par exemple, l’authentification peut échouer en raison d’un code d’autorisation expiré ou d’identifiants du client invalides.

Examinez la description de l’erreur dans le log d’échec pour déterminer la cause réelle. Les erreurs courantes non liées à DPoP comprennent : invalid_grant, invalid_client et les échecs de vérification de signature du ID token.

​

Échec de la génération de clé DPoP

Auth0 génère une paire de clés éphémère pour chaque preuve DPoP. Si la génération de clé échoue, l’authentification échoue avant l’envoi de la requête de jeton. Il s’agit d’un problème transitoire côté serveur. Demandez à l’utilisateur de réessayer l’authentification.

​

Liaison des jetons de l’IdP

Si l’authentification de l’utilisateur réussit, mais que les journaux du tenant Auth0 affichent "idp_token_type": "bearer", il se peut que votre IdP ne lie pas les jetons avec DPoP, même lorsque Auth0 envoie des preuves DPoP. Conformément à la RFC 9449, ce comportement est conforme. L’IdP décide entièrement s’il émet ou non des jetons liés à DPoP et peut ne pas lier les jetons pour les raisons suivantes :

• La politique de l’IdP n’exige pas DPoP pour la ressource ou l’application demandée.
• L’IdP ne prend pas en charge DPoP, même s’il accepte la preuve sans erreur.
• L’IdP a rencontré un problème interne lors du traitement de la preuve DPoP.

Auth0 consigne cela comme un événement « downgrade ». L’authentification se termine correctement avec des jetons Bearer standard.

Si vous avez besoin de jetons liés à DPoP pour des raisons de conformité, nous vous recommandons de communiquer avec votre IdP pour comprendre pourquoi les jetons ne sont pas liés. Auth0 ne peut pas imposer la liaison DPoP dans la réponse de jeton du fournisseur d’identité.

​

Gestion du nonce DPoP

Certains IdP exigent un nonce dans la preuve DPoP conformément au §8. Lorsque votre IdP renvoie un code HTTP 400 avec un en-tête de réponse DPoP-Nonce, Auth0 relance automatiquement la requête de jeton avec le nonce fourni. Ce mécanisme est transparent et n’apparaît pas comme un échec dans les journaux du tenant.

Le code d’erreur use_dpop_nonce est un signal de protocole interne entre Auth0 et l’IdP. Il n’indique aucun problème. Vous ne devriez pas voir use_dpop_nonce comme motif d’une entrée de journal d’échec. Si la nouvelle tentative avec le nonce échoue elle aussi (par exemple, si le fournisseur d’identité renvoie invalid_dpop_proof à la deuxième tentative), c’est l’erreur finale qui apparaît dans le journal d’échec.

Si vous observez des échecs d’authentification répétés sur une connexion où le fournisseur d’identité exige des nonces, vérifiez la connectivité réseau entre Auth0 et le fournisseur d’identité. L’échange de nonce nécessite deux allers-retours vers le point de terminaison de jeton, ce qui augmente la sensibilité aux délais d’expiration réseau.