Saltar al contenido principal
Demonstrating Proof-of-Possession (DPoP) es una extensión del framework OAuth 2.0. Para obtener más información sobre el protocolo DPoP y cómo se usa para vincular tokens al remitente, consulta Demonstrating Proof-of-Possession (DPoP). Si usas Okta u OpenID Connect (OIDC) como Proveedor de identidad (IdP) y los configuraste como una conexión empresarial en Auth0, puedes habilitar y configurar DPoP para vincular los tokens de acceso de tu IdP a claves criptográficas. El uso de DPoP evita ataques de reproducción de tokens y ayuda a cumplir requisitos normativos, como Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) OIDC Security Level 1 o Financial-grade API (FAPI) 2.0.

Antes de comenzar

Antes de habilitar DPoP en Auth0:
  • Tu Proveedor de identidad (IdP) ascendente debe ser compatible con DPoP según la especificación RFC-9449.
  • Debes tener una conexión empresarial de OIDC u Okta ya creada, o poder crear una. Para obtener más información sobre cómo crear una conexión empresarial en Auth0, consulta Enterprise Connections.
  • La conexión no debe estar configurada para usar Token Vault.
  • La conexión debe usar Proof Key for Code Exchange (PKCE) Authorization Code Flow + PKCE, que debe estar habilitado en el sistema ascendente si tu proveedor de identidad admite PKCE.
  • La conexión debe ser de tipo back_channel.

​
Verifique la compatibilidad del IdP de origen

Examine el documento de descubrimiento de OIDC de su IdP para determinar si admite DPoP: 
curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration
En la respuesta, busque el valor dpop_signing_alg_values_supported compatible con DPoP. Ejemplo 
{
  "dpop_signing_alg_values_supported": ["ES256", "ES384", "Ed25519", "ES512", "RS256"] 
},

​
Elija un algoritmo de firma

Antes de configurar DPoP, elija uno de los algoritmos de firma compatibles:
AlgoritmoDescripciónCuándo usarlo
ES256ECDSA con curva P-256 y SHA-256Su proveedor de identidad admite ES256.
ES384ECDSA con curva P-384 y SHA-384Su proveedor de identidad requiere ES384.
ES512ECDSA con curva P-521 y SHA-512Su proveedor de identidad requiere ES512.
Ed25519EdDSA con Curve25519Su proveedor de identidad requiere Ed25519 por motivos de cumplimiento.
Elija ES256, a menos que su proveedor de identidad requiera específicamente otro algoritmo.

​
Habilitar DPoP

Para habilitar DPoP y elegir un algoritmo, use Auth0 Dashboard o la Management API.
En Auth0 Dashboard:
  1. Vaya a Authentication > Enterprise. Seleccione la conexión que quiera configurar.
  2. Seleccione la pestaña Credentials.
  3. Marque la casilla Enable Demonstrating Proof of Possession (DPoP).
  4. En el menú Signing Algorithms for DPoP, elija el algoritmo.
    Habilitar DPoP y seleccionar un algoritmo
  5. Seleccione Save.

​
Probar DPoP

Después de habilitar DPoP, pruebe la configuración iniciando un flujo de inicio de sesión:
  1. Vaya a su aplicación.
  2. Inicie el flujo de inicio de sesión con la conexión empresarial configurada.
  3. Complete el inicio de sesión con su proveedor de identidad ascendente.
  4. Consulte los registros de Auth0 y vaya a Auth0 Dashboard > Monitoring > Logs para confirmarlo.
Una transacción correcta en una entrada de registro debería verse similar a: 
{
  "type": "s",
  "description": "Success Login",
  "details": {
    "dpop_signing_alg": "ES256",
    "idp_token_type": "dpop",
    "upstream_userinfo_fetch": {
      "status": "SUCCESS",
      "dpop_bound": true
    }
   }
}
Los valores dpop_signing_alg e idp_token_type: "dpop" confirman que Auth0 envió una prueba DPoP con el algoritmo configurado y que tu IdP emitió tokens vinculados a DPoP. El objeto upstream_userinfo_fetch solo está presente si se llama al endpoint de Información del usuario. El campo dpop_bound solo está presente si la solicitud GET al endpoint /userinfo queda correctamente vinculada a DPoP.

​
Deshabilitar DPoP

Puede deshabilitar DPoP con el Auth0 Dashboard o la Management API.
  1. Vaya a Authentication > Enterprise. Seleccione la conexión que desea configurar.
  2. Seleccione la pestaña Credentials.
  3. Desmarque la casilla Enable Demonstrating Proof of Possession (DPoP).
  4. Seleccione Save.

​
Solución de problemas

Use las siguientes recomendaciones para diagnosticar y resolver problemas con la configuración de DPoP para OIDC y las conexiones empresariales de Okta.

​
Compruebe la configuración de Auth0

Antes de empezar a solucionar problemas, compruebe la configuración de DPoP en Auth0:
  1. Vaya a Auth0 Dashboard > Authentication > Enterprise.
  2. Seleccione su conexión de Okta u OIDC.
  3. Verifique que la conexión no esté configurada con Token Vault. Para ello, vaya a Advanced Settings > Grant Types. Asegúrese de que Token Vault no esté seleccionado.
  4. Use el endpoint Update a connection de Management API para comprobar la configuración de dpop_signing_alg:
GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN
En la respuesta de dpop_signing_alg, compruebe lo siguiente:
  • Verifique que el algoritmo sea uno de los valores admitidos: ES256, ES384, ES512 o Ed25519.
  • Verifique que la conexión use el intercambio de tokens por back-channel mediante Authorization Code Flow + PKCE. DPoP no es compatible con las comunicaciones por front-channel, como en Implicit Flow, y se desactiva silenciosamente cuando la conexión usa el front-channel.

​
Faltan campos de DPoP en los registros del inquilino

Si los registros de éxito (s) o fallo (f) de Auth0 para la conexión empresarial no contienen los campos dpop_signing_alg o idp_token_type, podría deberse a una de las siguientes causas:
  • DPoP no está configurado. Verifique que dpop_signing_alg esté definido en el objeto options de la conexión mediante el endpoint Update a connection de la Management API, como se describió anteriormente.
  • Algoritmo no compatible. Auth0 admite ES256, ES384, ES512 y Ed25519. Si dpop_signing_alg está definido con un valor no compatible (por ejemplo, RS256), DPoP se desactiva silenciosamente. No se registra ningún error. Actualice la conexión para usar ES256, ES384, ES512 o Ed25519.
  • Conexión front-channel. DPoP requiere un tipo de conexión de intercambio de tokens back_channel. Es posible que deba actualizar el tipo de concesión a un flujo back-channel, como Authorization Code Flow o Authorization Code Flow + PKCE.

​
La autenticación falla después de habilitar DPoP

Revise las siguientes técnicas de solución de problemas si los usuarios no pueden completar la autenticación después de habilitar DPoP en su conexión empresarial de Okta u OIDC. Los registros del Tenant deberían mostrar un evento de error (f) con dpop_signing_alg, similar a: 
{
  "type": "f",
  "description": "Failed Login",
  "details": {
    "error": "dpop_signing_alg"
  }
}
Tenga en cuenta que el error no incluye idp_token_type porque Auth0 no recibió ningún token de su IdP.

​
El proveedor de identidad rechaza la prueba DPoP

El IdP puede rechazar activamente la prueba DPoP que Auth0 envía durante el intercambio de tokens. El IdP puede devolver un error invalid_dpop_proof, lo que hace que falle la autenticación. Compruebe que el IdP admita DPoP y que el algoritmo configurado (ES256, ES384, ES512 o Ed25519) esté en la lista de algoritmos compatibles. Puede comprobarlo accediendo al documento de descubrimiento de OpenID Connect del IdP: 
curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration
En la respuesta del IdP, busque dpop_signing_alg_values_supported. Si este campo no está presente, es posible que el IdP no admita DPoP. Si el campo solo enumera algoritmos que Auth0 no admite (por ejemplo, solo RS256), no se puede usar DPoP con esta conexión. Debe deshabilitar DPoP para esta conexión o ponerse en contacto con su IdP para habilitar la compatibilidad con ES256, ES384, ES512 o Ed25519.

​
El intercambio de tokens falla por un motivo no relacionado con DPoP

Si encuentra un registro de error en el que aparece dpop_signing_alg, eso no significa necesariamente que DPoP haya causado el fallo. Auth0 adjunta metadatos de DPoP a todos los registros de error cuando DPoP está configurado, incluso si la causa raíz no está relacionada. Por ejemplo, la autenticación podría fallar porque el code de autorización ha vencido o porque las credenciales del cliente no son válidas. Examine la descripción del error en el registro para determinar la causa real. Entre los errores habituales no relacionados con DPoP se incluyen invalid_grant, invalid_client y los errores de verificación de la firma del token de ID.

​
Error en la generación de claves DPoP

Auth0 genera un par de claves efímeras para cada prueba DPoP. Si se produce un error en la generación de claves, la autenticación falla antes de que se envíe la solicitud del token. Se trata de un problema transitorio del lado del servidor. Pida al usuario que vuelva a intentar la autenticación.

​
Vinculación de tokens del IdP

Si la autenticación del usuario se completa correctamente, pero los registros del inquilino de Auth0 muestran "idp_token_type": "bearer", es posible que su IdP no vincule los tokens a DPoP incluso cuando Auth0 envía pruebas de DPoP. Según la RFC 9449, este es un comportamiento conforme. El IdP tiene control total sobre si emite tokens vinculados a DPoP y puede no vincularlos por los siguientes motivos:
  • La política del IdP no requiere DPoP para el recurso o la aplicación solicitados.
  • El IdP no admite DPoP a pesar de aceptar la prueba sin errores.
  • El IdP encontró un problema interno al procesar la prueba de DPoP.
Auth0 realiza un seguimiento de esto como un evento de “downgrade”. La autenticación se completa correctamente con tokens Bearer estándar. Si necesita tokens vinculados a DPoP por motivos de cumplimiento normativo, le recomendamos que se ponga en contacto con su IdP para entender por qué no se están vinculando los tokens. Auth0 no puede forzar la vinculación a DPoP en la respuesta de token del proveedor de identidad.

​
Gestión del nonce de DPoP

Algunos Proveedores de identidad (IdP) requieren un nonce en la prueba DPoP según §8. Cuando el IdP devuelve un HTTP 400 con el encabezado de respuesta DPoP-Nonce, Auth0 reintenta automáticamente la solicitud de token con el nonce proporcionado. Esto se gestiona de forma transparente y no aparece como un fallo en los registros del inquilino. El código de error use_dpop_nonce es una señal interna del protocolo entre Auth0 y el IdP. No indica ningún problema. No deberías ver use_dpop_nonce como motivo de una entrada de registro de fallo. Si el reintento con el nonce también falla (por ejemplo, si el proveedor de identidad devuelve invalid_dpop_proof en el segundo intento), en el registro de fallos aparecerá el error final. Si observas fallos de autenticación repetidos en una conexión en la que el proveedor de identidad requiere nonces, comprueba la conectividad de red entre Auth0 y el proveedor de identidad. El intercambio de nonce requiere dos viajes de ida y vuelta al endpoint del token, lo que aumenta la sensibilidad a los tiempos de espera de la red.