> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Découvrez comment sécuriser les connexions d’entreprise OIDC et Okta au moyen d’une liaison cryptographique des jetons. # Configurer les connexions Enterprise avec Demonstrating Proof-of-Possession (DPoP) Demonstrating Proof-of-Possession (DPoP) est une [extension du framework OAuth 2.0](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/). 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)](/docs/fr-ca/secure/sender-constraining). 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](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1 ou [Financial-grade API (FAPI) 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html). Avant d’activer DPoP dans Auth0 : * Votre fournisseur d’identité en amont doit prendre en charge DPoP conformément à la spécification [RFC-9449](https://www.rfc-editor.org/rfc/rfc9449.html). * 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](/docs/fr-ca/authenticate/enterprise-connections). * La connexion ne doit pas être configurée pour utiliser [Token Vault](/docs/fr-ca/secure/call-apis-on-users-behalf/token-vault/configure-token-vault). * La connexion devrait utiliser le flux [flux de code d’autorisation + PKCE](docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce#authorization-code-flow-with-proof-key-for-code-exchange-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 theme={null} 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](/docs/fr-ca/get-started/applications/signing-algorithms) 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. Dans Auth0 Dashboard : 1. Accédez à **[Authentication > Enterprise](https://manage.auth0.com/dashboard/#/connections/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**. Pour utiliser la Management API, vous devez obtenir un [jeton d’accès à la Management API](/docs/fr-ca/secure/tokens/access-tokens/management-api-access-tokens). Effectuez une requête `PATCH` vers le point de terminaison [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) avec `dpop_signing_alg_values_supported` dans l’objet `options` : ```curl theme={null} 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](/docs/fr-ca/deploy-monitor/logs#logs) dans [**Auth0 Dashboard > Monitoring > Logs**](https://manage.auth0.com/#/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](https://auth0.com/docs/api/authentication/user-profile/get-user-info) 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. 1. Accédez à [**Authentication > Enterprise**](https://manage.auth0.com/dashboard/#/connections/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**. Pour désactiver DPoP, supprimez la propriété `dpop_signing_alg` de la configuration de votre connexion : ```curl theme={null} 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**](https://manage.auth0.com/#/connections/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](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) du Management API pour vérifier le paramètre `dpop_signing_alg` : ```curl theme={null} 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). DPoP n’est pas pris en charge pour les communications en front-channel, comme dans le [Flux implicite](/docs/fr-ca/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post), 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](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) 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](/docs/fr-ca/get-started/applications/update-grant-types#update-grant-types) 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 à : ```bash theme={null} { "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 theme={null} 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](https://www.rfc-editor.org/rfc/rfc9449.html#name-authorization-server-provid). 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.