From 61e9d589254712c80c68f139e950c43c3e230042 Mon Sep 17 00:00:00 2001 From: amanda-vanscoy Date: Mon, 6 Apr 2026 17:26:13 -0400 Subject: [PATCH 1/5] First draft DPoP for Enterprise Connections --- .../enable-dpop-enterprise-connections.mdx | 111 ++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx diff --git a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx new file mode 100644 index 0000000000..e4647b7574 --- /dev/null +++ b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx @@ -0,0 +1,111 @@ +--- +description: Learn how to enable Demonstrating Proof-of-Possession (DPoP) to secure OIDC and Okta enterprise connections with cryptographic token binding. +title: Enable DPoP for Enterprise Connections +--- + + +Demonstrating Proof-of-Possession (DPoP) for Enterprise connections is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). To request access to the feature, contact your account team or [Auth0 Support](https://support.auth0.com). + + +Demonstrating Proof-of-Possession (DPoP) is an [OAuth 2.0 framework extension](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) that binds or [sender constrains](/docs/secure/sender-constraining) access tokens using asymmetric cryptography and JSON Web Tokens (JWTs) at the application layer. If you use Okta or OpenID Connect (OIDC) as your identity provider (IdP) and have configured them as an Enterprise connection in Auth0, then you can enable and configure DPoP to bind access tokens from your IdP to cryptographic keys. Using DPoP prevents token replay attacks and helps meet compliance requirements, such as [IPSIE OIDC](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1. + +To learn more about DPoP, read [Demonstrating Proof-of-Possession (DPoP)](/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop). + +## Prerequisites + +Before you enable DPoP in Auth0: + +* Your upstream identity provider must support DPoP according to specification [RFC-9449](https://www.rfc-editor.org/rfc/rfc9449.html). +* You must have an existing OIDC or Okta Enterprise connection or be able to create one. To learn how to create an Enterprise connection in Auth0, read [Enterprise Connections](/docs/authenticate/enterprise-connections). +* The connection must not be configured to use [Token Vault](/docs/secure/call-apis-on-users-behalf/token-vault/configure-token-vault). +* The connection should use Proof Key for Code Exchange (PKCE) [Authorization Code Flow + PKCE](docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce#authorization-code-flow-with-proof-key-for-code-exchange-pkce), which is enabled upstream if your identity provider supports PKCE. + +## Verify upstream IdP support + +Examine your IdP's OIDC discovery document to determine the DPoP support: + +```curl +curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration +``` + +In the response, search for DPoP supported values, `dpop_signing_alg_values_supported`. + +**Example** + +``` +{ + "dpop_signing_alg_values_supported": ["ES256", "Ed25519", "RS256"] +}, +``` + +## Choose a signing algorithm + +Before you configure DPoP, choose a supported [signing algorithm](/docs/get-started/applications/signing-algorithms) from the options: + +| **Algorithm** | **Description** | **When to use** | +| ------- | ------- | ------- | +| ES256 | ECDSA with P-256 curve and SHA-256 | Your identity provider supports ES256. | +| Ed25519 | EdDSA with Curve25519 | Your identity provider requires Ed25519 for compliance. | + +Choose ES256 unless your identity provider specifically requires Ed25519. Most identity providers support ES256, and it provides equivalent security with broad compatibility. + +## Enable DPoP + +Use the Management API to configure the DPoP JWT claim, `alg`, the signing algorithm for your Enterprise connection. To use the Management API, you need to get a [Management API access token](/docs/secure/tokens/access-tokens/management-api-access-tokens). + +Make a `PATCH` request to the [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) endpoint with `dpop_signing_alg_values_supported` in the `options` object: + +```curl +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" + } +} +``` +Replace the placeholder values: + +* **YOUR_DOMAIN**: Your Auth0 tenant domain. Example: `travel0.us.auth0.com`. +* **YOUR_CONNECTION_ID**: The ID of your OIDC or Okta Enterprise connection. +* **YOUR_MANAGEMENT_API_TOKEN**: A Management API token with `update:connections` scope + +## Test DPoP + +After enabling DPoP, test the configuration by initiating a login flow: + +1. Navigate to your application. +2. Start a login using your configured Enterprise connection. +3. Complete authentication with your upstream identity provider. +4. [Check Auth0 logs](/docs/deploy-monitor/logs#logs) by navigating to [**Auth0 Dashboard > Monitoring > Logs**](https://manage.auth0.com/#/logs) for confirmation. + +A sucessful transaction in a log entry should be similar to: + +``` +{ + "type": "s", + "description": "Success Login", + "details": { + "dpop_signing_alg": "ES256", + } +} +``` + +## Disable DPoP + +To disable DPoP, remove the `dpop_signing_alg` property from your connection configuration: + +```curl +PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID +Content-Type: application/json +Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN + +{ + "options": { + + } +} + +``` \ No newline at end of file From 2a890aa42de772b381f69ce2c25c715089bf9518 Mon Sep 17 00:00:00 2001 From: amanda-vanscoy Date: Tue, 7 Apr 2026 11:47:10 -0400 Subject: [PATCH 2/5] Adding troubleshooting tips --- main/docs.json | 3 +- .../enable-dpop-enterprise-connections.mdx | 116 +++++++++++++++++- 2 files changed, 114 insertions(+), 5 deletions(-) diff --git a/main/docs.json b/main/docs.json index 18c396ad0a..824c6be99e 100644 --- a/main/docs.json +++ b/main/docs.json @@ -1979,7 +1979,8 @@ "docs/secure/sender-constraining", "docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop", "docs/secure/sender-constraining/mtls-sender-constraining", - "docs/secure/sender-constraining/configure-sender-constraining" + "docs/secure/sender-constraining/configure-sender-constraining", + "docs/secure/sender-constraining/enable-dpop-enterprise-connections" ] }, { diff --git a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx index e4647b7574..316203fb76 100644 --- a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx +++ b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx @@ -4,14 +4,14 @@ title: Enable DPoP for Enterprise Connections --- -Demonstrating Proof-of-Possession (DPoP) for Enterprise connections is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). To request access to the feature, contact your account team or [Auth0 Support](https://support.auth0.com). +Demonstrating Proof-of-Possession (DPoP) for Enterprise connections is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). Demonstrating Proof-of-Possession (DPoP) is an [OAuth 2.0 framework extension](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) that binds or [sender constrains](/docs/secure/sender-constraining) access tokens using asymmetric cryptography and JSON Web Tokens (JWTs) at the application layer. If you use Okta or OpenID Connect (OIDC) as your identity provider (IdP) and have configured them as an Enterprise connection in Auth0, then you can enable and configure DPoP to bind access tokens from your IdP to cryptographic keys. Using DPoP prevents token replay attacks and helps meet compliance requirements, such as [IPSIE OIDC](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1. To learn more about DPoP, read [Demonstrating Proof-of-Possession (DPoP)](/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop). -## Prerequisites + Before you enable DPoP in Auth0: @@ -19,6 +19,9 @@ Before you enable DPoP in Auth0: * You must have an existing OIDC or Okta Enterprise connection or be able to create one. To learn how to create an Enterprise connection in Auth0, read [Enterprise Connections](/docs/authenticate/enterprise-connections). * The connection must not be configured to use [Token Vault](/docs/secure/call-apis-on-users-behalf/token-vault/configure-token-vault). * The connection should use Proof Key for Code Exchange (PKCE) [Authorization Code Flow + PKCE](docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce#authorization-code-flow-with-proof-key-for-code-exchange-pkce), which is enabled upstream if your identity provider supports PKCE. +* The connection must be type `back_channel`. + + ## Verify upstream IdP support @@ -28,7 +31,7 @@ Examine your IdP's OIDC discovery document to determine the DPoP support: curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration ``` -In the response, search for DPoP supported values, `dpop_signing_alg_values_supported`. +In the response, search for the DPoP supported value `dpop_signing_alg_values_supported`. **Example** @@ -108,4 +111,109 @@ Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN } } -``` \ No newline at end of file +``` + +## Troubleshoot + +Use the following recommendations to help diagnose and resolve issues with DPoP configuration for OIDC and Okta enterprise connections. + +### Check configuration + +Before you start to troubleshoot, verify your DPoP configuration. + +1. Navigate to [**Auth0 Dashboard > Authentication > Enterprise**](https://manage.auth0.com/#/connections/enterprise). +2. Select your Okta or OIDC connection. +3. Verify the connection is **not** configured with Token Vault by navigating to **Advanced Settings > Grant Types**. Make sure Token Vault is not selected. +4. Use Management API's [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) endpoint to check the `dpop_signing_alg` setting: + +```curl +GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID +Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN +``` +Check for the `dpop_signing_alg` property in the response: + +```bash +{ + "options": { + "dpop_signing_alg": "ES256" + } +} +``` + +### Authentication fails after enabling DPoP + +Review the following troubleshooting techniques if your users cannot complete authentication after you have enabled DPoP on your Okta or OIDC enterprise connection. + +#### Identity provider does not support DPoP + +Check the IdP's OpenID Connect discovery document: + +```curl +curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration +``` + +If `dpop_signing_alg_values_supported` is missing, then the identity provider does not support DPoP. You need to disable DPoP for this connection or contact your identity provider to enable DPoP support. + +#### Mismatch algorithm + +The identity provider may not support the algorithm you configured. Check the supported algorithms in the discovery for the algorithm you selected for DPoP with Auth0: + +``` +{ + "dpop_signing_alg_values_supported": ["RS256"] +} +``` + +If your identity provider supports only **RS256**, DPoP is not available during Early Access. Disable DPoP or wait for RSA algorithm support. + +#### Token Vault conflict + +DPoP is not compatible with Token Vault. Check your connection configuration with Management API's [Get a connection](https://auth0.com/docs/api/management/v2/connections/get-connections-by-id) endpoint: + +```curl +GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID +``` + +If `upstream_params.offline_access` is set to `true`, or the connection is configured for Token Vault, you must disable Token Vault before enabling DPoP. + +### Reject proof validation + +Review the following troubleshooting techniques if you find authentication failures related to DPoP proof validation. + +#### Nonce requirement + +Some IdP's require a `nonce` in the DPoP proof. Auth0 handles nonce requirements automatically, but network issues can prevent nonce exchange. + +Review Auth0 logs for the following error: + +```bash +{ + "type": "f", + "description": "Failed Login", + "details": { + "error": "use_dpop_nonce" + } +} +``` + +This error indicates a transient issue. Ask the user to retry authentication. If the issue persists, check network connectivity between Auth0 and the identity provider. + +#### IdP token binding + +If user authentication succeeds, but Auth0 logs show `dpop_returned_from_upstream: false`, then your IdP might not bind tokens with DPoP even when Auth0 sends DPoP proofs. This may occur when: + +* The requested resource does not support DPoP. +* The IdP's policy does not allow DPoP for specific scenarios. +* The IdP encountered an error processing the DPoP proof. + +Start troubleshooting by checking the IdP's response. If `token_type` is `Bearer` instead of `DPoP` as shown in the example, the IdP issued a standard bearer token. + +**Example** + +``` +{ + "access_token": "eyJ...", + "token_type": "Bearer" +} +``` + From fba61432b467308cb4392c89878fa8b564dccf7b Mon Sep 17 00:00:00 2001 From: amanda-vanscoy Date: Tue, 7 Apr 2026 16:49:37 -0400 Subject: [PATCH 3/5] Updated content for Troubleshoot --- .../enable-dpop-enterprise-connections.mdx | 104 ++++++++---------- 1 file changed, 47 insertions(+), 57 deletions(-) diff --git a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx index 316203fb76..51d4abaeae 100644 --- a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx +++ b/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx @@ -92,10 +92,13 @@ A sucessful transaction in a log entry should be similar to: "description": "Success Login", "details": { "dpop_signing_alg": "ES256", + "idp_token_type": "dpop" } } ``` +Both values, `dpop_signing_alg` and `idp_token_type: "dpop"` confirm Auth0 sent a DPoP proof using the configured algorithm and your IdP issued DPoP-bound tokens. + ## Disable DPoP To disable DPoP, remove the `dpop_signing_alg` property from your connection configuration: @@ -117,9 +120,9 @@ Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN Use the following recommendations to help diagnose and resolve issues with DPoP configuration for OIDC and Okta enterprise connections. -### Check configuration +### Check Auth0 configuration -Before you start to troubleshoot, verify your DPoP configuration. +Before you start to troubleshoot, verify your DPoP configuration in Auth0. 1. Navigate to [**Auth0 Dashboard > Authentication > Enterprise**](https://manage.auth0.com/#/connections/enterprise). 2. Select your Okta or OIDC connection. @@ -130,90 +133,77 @@ Before you start to troubleshoot, verify your DPoP configuration. GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN ``` -Check for the `dpop_signing_alg` property in the response: +In the `dpop_signing_alg` response, check for the following: -```bash -{ - "options": { - "dpop_signing_alg": "ES256" - } -} -``` +* Verify the algorithm is one of the supported values: **ES256** or **Ed25519**. +* Verify that the connection uses back-channel token exchange using [Authorization Code Flow + PKCE](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). DPoP is not supported for front-channel communications as in [Implicit Flow](/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) and is silently disabled when the connection uses the front-channel. -### Authentication fails after enabling DPoP +#### DPoP fields missing in tenant logs -Review the following troubleshooting techniques if your users cannot complete authentication after you have enabled DPoP on your Okta or OIDC enterprise connection. +If Auth0 success (`s`) or failure (`f`) logs for the enterprise connection do not contain `dpop_signing_alg` or `idp_token_type` fields, it could be due to one of the following causes: -#### Identity provider does not support DPoP +* DPoP is not configured. Verify `dpop_signing_alg` is set in the connection options using the Management API's [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) endpoint as described above. +* Unsupported algorithm. Auth0 supports ES256 and Ed25519 during Early Access. If `dpop_signing_alg` is set to an unsupported value (for example, RS256), DPoP is silently disabled. No error is logged. Update the connection to use ES256 or Ed25519. +* Front-channel connection. DPoP requires a connection type of `back_channel` token exchange. You may need to [update the grant type](/docs/get-started/applications/update-grant-types#update-grant-types) to a back-channel flow like Authorization Code Flow or Authorization Code Flow + PKCE. -Check the IdP's OpenID Connect discovery document: - -```curl -curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration -``` - -If `dpop_signing_alg_values_supported` is missing, then the identity provider does not support DPoP. You need to disable DPoP for this connection or contact your identity provider to enable DPoP support. +### Authentication fails after enabling DPoP -#### Mismatch algorithm +Review the following troubleshooting techniques if your users cannot complete authentication after you have enabled DPoP on your Okta or OIDC enterprise connection. -The identity provider may not support the algorithm you configured. Check the supported algorithms in the discovery for the algorithm you selected for DPoP with Auth0: +Tenant logs should display a failure (`f`) event with `dpop_signing_alg` similar to: -``` +```bash { - "dpop_signing_alg_values_supported": ["RS256"] + "type": "f", + "description": "Failed Login", + "details": { + "error": "dpop_signing_alg" + } } ``` -If your identity provider supports only **RS256**, DPoP is not available during Early Access. Disable DPoP or wait for RSA algorithm support. +Note the failure does not include the `idp_token_type` because Auth0 did not recieve a token from your IdP. -#### Token Vault conflict +#### Identity provider rejects DPoP proof -DPoP is not compatible with Token Vault. Check your connection configuration with Management API's [Get a connection](https://auth0.com/docs/api/management/v2/connections/get-connections-by-id) endpoint: +The IdP may actively reject the DPoP proof Auth0 sends during token exchange. The IdP may return an `invalid_dpop_proof` error, causing authentication to fail. + +Check the IdP supports DPoP and if the configured algorithm (either ES256 or Ed25519) is in the supported list. You can find out by accessing the IdP's OpenID Connect discovery document: ```curl -GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID +curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration ``` -If `upstream_params.offline_access` is set to `true`, or the connection is configured for Token Vault, you must disable Token Vault before enabling DPoP. +In the IdP response, look for `dpop_signing_alg_values_supported`. If this field is missing, the IdP may not support DPoP. If the field lists only algorithms that Auth0 does not support (for example, only RS256), DPoP cannot be used with this connection during Early Access. You should disable DPoP for this connection or contact your IdP to enable support for ES256 or Ed25519. -### Reject proof validation +#### Token exchange fails for a non-DPoP reason -Review the following troubleshooting techniques if you find authentication failures related to DPoP proof validation. +If you find a failure log with `dpop_signing_alg` present, this does not necessarily mean DPoP caused the failure. Auth0 attaches DPoP metadata to all failure logs when DPoP is configured, even if the root cause is unrelated. For example, authentication could fail due to an expired authorization code or invalid client credentials. -#### Nonce requirement +Examine the error description in the failure log to determine the actual cause. Common non-DPoP errors include: `invalid_grant`, `invalid_client`, and ID token signature verification failures. -Some IdP's require a `nonce` in the DPoP proof. Auth0 handles nonce requirements automatically, but network issues can prevent nonce exchange. +#### DPoP key generation fails -Review Auth0 logs for the following error: +Auth0 generates an ephemeral key pair for each DPoP proof. If key generation fails, authentication fails before the token request is sent. This is a transient server-side issue. Ask the user to retry authentication. -```bash -{ - "type": "f", - "description": "Failed Login", - "details": { - "error": "use_dpop_nonce" - } -} -``` +#### IdP token binding -This error indicates a transient issue. Ask the user to retry authentication. If the issue persists, check network connectivity between Auth0 and the identity provider. +If user authentication succeeds, but Auth0 tenant logs show `"idp_token_type": "bearer"`, then your IdP might not bind tokens with DPoP even when Auth0 sends DPoP proofs. Per RFC-9449, this is compliant behavior. The IdP has full control over whether to issue DPoP-bound tokens and may not bind tokens because: -#### IdP token binding +* The IdP's policy does not require DPoP for the requested resource or application. +* The IdP does not support DPoP despite accepting the proof without error. +* The IdP encountered an internal issue processing the DPoP proof. -If user authentication succeeds, but Auth0 logs show `dpop_returned_from_upstream: false`, then your IdP might not bind tokens with DPoP even when Auth0 sends DPoP proofs. This may occur when: +Auth0 tracks this as a "downgrade" event. Authentication completes successfully with standard Bearer tokens. -* The requested resource does not support DPoP. -* The IdP's policy does not allow DPoP for specific scenarios. -* The IdP encountered an error processing the DPoP proof. +If you require DPoP-bound tokens for compliance, we recommend you contact your IdP to understand why tokens are not being bound. Auth0 cannot enforce DPoP binding on the identity provider's token response. -Start troubleshooting by checking the IdP's response. If `token_type` is `Bearer` instead of `DPoP` as shown in the example, the IdP issued a standard bearer token. +#### DPoP nonce handling -**Example** +Some IdP's require a `nonce` in the [DPoP proof per §8](https://www.rfc-editor.org/rfc/rfc9449.html#name-authorization-server-provid). When your IdP returns HTTP `400` with a `DPoP-Nonce` response header, Auth0 automatically retries the token request with the provided nonce. This is handled transparently and does not appear as a failure in tenant logs. + +The `use_dpop_nonce` error code is an internal protocol signal between Auth0 and the IdP. It does not indicate a problem. You should not see `use_dpop_nonce` as the reason for a failure log entry. If the retry with the nonce also fails (for example, the identity provider returns `invalid_dpop_proof` on the second attempt), the ultimate error is what appears in the failure log. + +If you observe repeated authentication failures on a connection where the identity provider requires nonces, check network connectivity between Auth0 and the identity provider. Nonce exchange requires two round-trips to the token endpoint, which increases sensitivity to network timeouts. -``` -{ - "access_token": "eyJ...", - "token_type": "Bearer" -} -``` From fbe6e3c80c270d6d09aa64ac436ab9f6f1cf46cb Mon Sep 17 00:00:00 2001 From: amanda-vanscoy Date: Wed, 8 Apr 2026 14:39:55 -0400 Subject: [PATCH 4/5] Updated nav location and title/description to reflect section change --- main/docs.json | 6 +++--- .../enable-dpop-enterprise-connections.mdx | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) rename main/docs/{secure/sender-constraining => authenticate/enterprise-connections}/enable-dpop-enterprise-connections.mdx (95%) diff --git a/main/docs.json b/main/docs.json index 824c6be99e..d82a17e0ba 100644 --- a/main/docs.json +++ b/main/docs.json @@ -849,7 +849,8 @@ "docs/authenticate/enterprise-connections/user-attribute-profile" ] }, - "docs/authenticate/enterprise-connections/private-key-jwt-client-auth" + "docs/authenticate/enterprise-connections/private-key-jwt-client-auth", + "docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections" ] }, { @@ -1979,8 +1980,7 @@ "docs/secure/sender-constraining", "docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop", "docs/secure/sender-constraining/mtls-sender-constraining", - "docs/secure/sender-constraining/configure-sender-constraining", - "docs/secure/sender-constraining/enable-dpop-enterprise-connections" + "docs/secure/sender-constraining/configure-sender-constraining" ] }, { diff --git a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx b/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx similarity index 95% rename from main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx rename to main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx index 51d4abaeae..56ca03541c 100644 --- a/main/docs/secure/sender-constraining/enable-dpop-enterprise-connections.mdx +++ b/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx @@ -1,10 +1,10 @@ --- -description: Learn how to enable Demonstrating Proof-of-Possession (DPoP) to secure OIDC and Okta enterprise connections with cryptographic token binding. -title: Enable DPoP for Enterprise Connections +description: Learn how to secure OIDC and Okta Enterprise connections with cryptographic token binding. +title: Configure Enterprise Connections with Demonstrating Proof-of-Possession (DPoP) --- -Demonstrating Proof-of-Possession (DPoP) for Enterprise connections is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). +Enterprise Connections with Demonstrating Proof-of-Possession (DPoP) is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). Demonstrating Proof-of-Possession (DPoP) is an [OAuth 2.0 framework extension](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) that binds or [sender constrains](/docs/secure/sender-constraining) access tokens using asymmetric cryptography and JSON Web Tokens (JWTs) at the application layer. If you use Okta or OpenID Connect (OIDC) as your identity provider (IdP) and have configured them as an Enterprise connection in Auth0, then you can enable and configure DPoP to bind access tokens from your IdP to cryptographic keys. Using DPoP prevents token replay attacks and helps meet compliance requirements, such as [IPSIE OIDC](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1. From 867c86ed64af8fafcc5b4932239cdb36e1f72b0a Mon Sep 17 00:00:00 2001 From: amanda-vanscoy Date: Thu, 9 Apr 2026 12:21:09 -0400 Subject: [PATCH 5/5] Address comments --- .../enable-dpop-enterprise-connections.mdx | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx b/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx index 56ca03541c..581c9179a5 100644 --- a/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx +++ b/main/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections.mdx @@ -7,7 +7,7 @@ title: Configure Enterprise Connections with Demonstrating Proof-of-Possession ( Enterprise Connections with Demonstrating Proof-of-Possession (DPoP) is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in [Okta’s Master Subscription Agreement](https://www.okta.com/legal). To learn more about product release stages, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). -Demonstrating Proof-of-Possession (DPoP) is an [OAuth 2.0 framework extension](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) that binds or [sender constrains](/docs/secure/sender-constraining) access tokens using asymmetric cryptography and JSON Web Tokens (JWTs) at the application layer. If you use Okta or OpenID Connect (OIDC) as your identity provider (IdP) and have configured them as an Enterprise connection in Auth0, then you can enable and configure DPoP to bind access tokens from your IdP to cryptographic keys. Using DPoP prevents token replay attacks and helps meet compliance requirements, such as [IPSIE OIDC](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1. +Demonstrating Proof-of-Possession (DPoP) is an [OAuth 2.0 framework extension](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/). To learn more about DPoP protocol and how it is used to sender constrain tokens, read [Demonstrating Proof-of-Possession (DPoP)](/docs/secure/sender-constraining). If you use Okta or OpenID Connect (OIDC) as your identity provider (IdP) and have configured them as an Enterprise connection in Auth0, then you can enable and configure DPoP to bind access tokens from your IdP to cryptographic keys. Using DPoP prevents token replay attacks and helps meet compliance requirements, such as [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 or [Financial-grade API (FAPI) 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html). To learn more about DPoP, read [Demonstrating Proof-of-Possession (DPoP)](/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop). @@ -69,6 +69,10 @@ Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN } } ``` + + If you `PATCH` the `options` parameter, the entire `options` object is overridden. To avoid partial data or other issues, ensure all wanted properties are present when you PATCH `option`. + + Replace the placeholder values: * **YOUR_DOMAIN**: Your Auth0 tenant domain. Example: `travel0.us.auth0.com`. @@ -80,8 +84,8 @@ Replace the placeholder values: After enabling DPoP, test the configuration by initiating a login flow: 1. Navigate to your application. -2. Start a login using your configured Enterprise connection. -3. Complete authentication with your upstream identity provider. +2. Start the login flow using your configured Enterprise connection. +3. Complete login with your upstream identity provider. 4. [Check Auth0 logs](/docs/deploy-monitor/logs#logs) by navigating to [**Auth0 Dashboard > Monitoring > Logs**](https://manage.auth0.com/#/logs) for confirmation. A sucessful transaction in a log entry should be similar to: @@ -113,9 +117,12 @@ Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN } } - ``` + + If you `PATCH` the `options` parameter, the entire `options` object is overridden. To avoid partial data or other issues, ensure all wanted properties are present when you PATCH `option`. + + ## Troubleshoot Use the following recommendations to help diagnose and resolve issues with DPoP configuration for OIDC and Okta enterprise connections. @@ -142,7 +149,7 @@ In the `dpop_signing_alg` response, check for the following: If Auth0 success (`s`) or failure (`f`) logs for the enterprise connection do not contain `dpop_signing_alg` or `idp_token_type` fields, it could be due to one of the following causes: -* DPoP is not configured. Verify `dpop_signing_alg` is set in the connection options using the Management API's [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) endpoint as described above. +* DPoP is not configured. Verify `dpop_signing_alg` is set in the connection `options` object using the Management API's [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) endpoint as described above. * Unsupported algorithm. Auth0 supports ES256 and Ed25519 during Early Access. If `dpop_signing_alg` is set to an unsupported value (for example, RS256), DPoP is silently disabled. No error is logged. Update the connection to use ES256 or Ed25519. * Front-channel connection. DPoP requires a connection type of `back_channel` token exchange. You may need to [update the grant type](/docs/get-started/applications/update-grant-types#update-grant-types) to a back-channel flow like Authorization Code Flow or Authorization Code Flow + PKCE.