Passer au contenu principal
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 est utilisé pour lier les jetons à l’expéditeur, consultez Demonstrating Proof-of-Possession (DPoP). Si vous utilisez Okta ou OpenID Connect (OIDC) comme fournisseur d’identité (IdP) et que vous l’avez configuré 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 contribue à 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 disposer d’une connexion d’entreprise OIDC ou Okta existante, ou être en mesure d’en créer une. Pour savoir comment créer une connexion d’entreprise dans Auth0, consultez Connexions d’entreprise.
  • La connexion ne doit pas être configurée pour utiliser Token Vault.
  • La connexion devrait utiliser Proof Key for Code Exchange (PKCE) Authorization Code Flow + PKCE, qui est activé en amont si votre fournisseur d’identité prend en charge PKCE.
  • La connexion doit être de type back_channel.

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

Consultez 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 :
AlgorithmeDescriptionQuand l’utiliser
ES256ECDSA avec la courbe P-256 et SHA-256Votre fournisseur d’identité prend en charge ES256.
ES384ECDSA avec la courbe P-384 et SHA-384Votre fournisseur d’identité exige ES384.
ES512ECDSA avec la courbe P-521 et SHA-512Votre fournisseur d’identité exige ES512.
Ed25519EdDSA avec Curve25519Votre fournisseur d’identité exige Ed25519 pour des raisons de conformité.
Choisissez ES256, sauf si votre fournisseur d’identité exige explicitement un autre algorithme.

​
Activer DPoP

Pour activer DPoP et choisir un algorithme, utilisez Auth0 Dashboard ou Management API.
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.
    Activer DPoP et sélectionner un algorithme
  5. Sélectionnez Save.

​
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é.
  4. Consultez les journaux d’Auth0 en accédant à Auth0 Dashboard > Monitoring > Logs pour confirmer.
Une transaction réussie dans une entrée de journal devrait ressembler à : 
{
  "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’apparaît que si le point de terminaison Informations sur l’utilisateur est appelé. Le champ dpop_bound n’apparaît 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 à partir d’Auth0 Dashboard ou de la Management API.
  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 Save.

​
Dépannage

Utilisez les recommandations suivantes pour vous aider à 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 pour utiliser 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 de la 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 points suivants :
  • Vérifiez que l’algorithme correspond à l’une des valeurs prises en charge : ES256, ES384, ES512 ou Ed25519.
  • Vérifiez que la connexion utilise l’échange de jeton par back-channel avec Authorization Code Flow + PKCE. DPoP n’est pas pris en charge pour les communications en front-channel, comme avec Implicit Flow, et est désactivé silencieusement lorsque la connexion utilise le front-channel.

​
Champs DPoP manquants dans les journaux du locataire

Si les journaux 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 à une valeur non prise en charge (par exemple, RS256), DPoP est désactivé sans avertissement. Aucune erreur n’est consignée. Mettez à jour la connexion pour utiliser ES256, ES384, ES512 ou Ed25519.
  • Connexion front-channel. DPoP nécessite un type de connexion d’échange de jeton back_channel. Vous devrez peut-être mettre à jour le type d’octroi vers un flux back-channel, comme Authorization Code Flow ou Authorization Code Flow + PKCE.

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

Consultez les méthodes de dépannage suivantes si vos utilisateurs ne parviennent pas à terminer l’authentification après avoir activé DPoP sur votre connexion d’entreprise Okta ou OIDC. Les journaux du locataire 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 la réponse d’échec n’inclut pas idp_token_type, car Auth0 n’a pas reçu de jeton de votre IdP.

​
Le fournisseur d’identité rejette la preuve DPoP

L’IdP peut rejeter explicitement la preuve DPoP qu’Auth0 envoie lors de 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 dans la liste des algorithmes pris en charge. Vous pouvez le vérifier 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 indique uniquement des algorithmes qu’Auth0 ne prend pas en charge (par exemple, RS256 seulement), DPoP ne peut pas être utilisé avec cette connexion. Vous devriez désactiver DPoP pour cette connexion ou communiquer avec votre IdP pour faire activer la prise en charge d’ES256, d’ES384, d’ES512 ou d’Ed25519.

​
L’échange de jeton échoue pour une raison non liée à DPoP

Si vous trouvez un journal d’échec dans lequel dpop_signing_alg est présent, cela ne signifie pas nécessairement que DPoP est à l’origine de l’échec. Auth0 ajoute des métadonnées DPoP à tous les journaux d’échec lorsque DPoP est configuré, même si la cause réelle n’a aucun lien avec DPoP. Par exemple, l’authentification peut échouer en raison d’un code d’autorisation expiré ou d’identifiants d’application invalides. Examinez la description de l’erreur dans le journal d’échec pour déterminer la cause exacte. Les erreurs courantes non liées à DPoP comprennent : invalid_grant, invalid_client et les échecs de vérification de la signature du jeton d’identité.

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

Auth0 génère une paire de clés éphémère pour chaque preuve DPoP. Si la génération de la clé échoue, l’authentification échoue avant l’envoi de la demande de jeton. Il s’agit d’un problème temporaire 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 locataire Auth0 affichent "idp_token_type": "bearer", il se peut que votre IdP ne lie pas les jetons à DPoP, même lorsque Auth0 envoie des preuves DPoP. Selon la RFC 9449, ce comportement est conforme. L’IdP contrôle entièrement s’il émet ou non des jetons liés à DPoP et peut ne pas lier les jetons pour les raisons suivantes :
  • La stratégie 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 de « downgrade ». L’authentification se termine correctement avec des jetons Bearer standard. Si vous exigez des 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 fournisseurs d’identité (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 comportement est géré de façon transparente et n’apparaît pas comme un échec dans les journaux du locataire. Le code d’erreur use_dpop_nonce est un signal de protocole interne entre Auth0 et l’IdP. Il n’indique pas un problème. Vous ne devriez pas voir use_dpop_nonce comme cause d’une entrée de journal d’échec. Si la nouvelle tentative avec le nonce échoue 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 du nonce nécessite deux allers-retours vers le point de terminaison du jeton, ce qui accroît la sensibilité aux délais d’expiration réseau.