Configurar la restricción del remitente

Descripción general de cómo configurar la restricción del remitente para tu Tenant de Auth0.

La restricción del remitente es un mecanismo de seguridad de OAuth 2.0 y OpenID Connect (OIDC) que vincula criptográficamente los tokens de acceso y los tokens de actualización con la aplicación cliente específica que los obtuvo, lo que evita el robo y el uso indebido de tokens.

Auth0 admite la restricción del remitente con mTLS y Demonstrating Proof-of-Possession (DPoP). Si habilitas la restricción del remitente para una aplicación cliente, también debes exigirla para el servidor de recursos al que haces llamadas a la API.

Para configurar la restricción del remitente en Auth0, debes:

• Configurar la restricción del remitente para una aplicación cliente
• Configurar la restricción del remitente para un servidor de recursos

​

Cómo funciona

Tokens de acceso tienen restricción del remitente en Auth0 en función de cómo configures la restricción del remitente para tu aplicación cliente y tu servidor de recursos:

1. Audiencia solicitada: En una solicitud de token, influye en si los tokens de acceso tienen restricción del remitente el hecho de que la audiencia solicitada sea solo /userinfo, que esté destinada únicamente a usarse con el endpoint /userinfo, o que sea una API personalizada que puede incluir /userinfo cuando también solicitas el scope openid.

2. Aplicación cliente: Si estableces la restricción del remitente como required para la aplicación cliente.

3. Servidor de recursos: Si configuras la restricción del remitente para el servidor de recursos:

   1. none: No has configurado la restricción del remitente para el servidor de recursos.
   2. allowed: Has configurado la restricción del remitente para el servidor de recursos estableciendo un método de restricción del remitente.
   3. required: Has configurado la restricción del remitente como obligatoria para el servidor de recursos, lo que significa que los tokens de acceso deben tener restricción del remitente para una aplicación. Puedes exigir la restricción del remitente para todas las aplicaciones o solo para las aplicaciones públicas. Requiere un método de restricción del remitente.

Al usar mTLS como método de restricción del remitente, la restricción del remitente siempre es obligatoria para todas las aplicaciones. Las aplicaciones públicas no son compatibles con mTLS, por lo que no puedes limitar la restricción del remitente con mTLS solo a clientes públicos.

• Proof-of-Possession: Si la aplicación cliente envió una aserción de prueba de posesión en la solicitud de token:

  • Restricción del remitente con mTLS: La prueba de posesión se demuestra mediante la presentación satisfactoria por parte del cliente de una clave privada específica (asociada a un certificado de cliente) durante el handshake de TLS.
  • DPoP: La prueba de posesión se logra cuando el cliente crea un JWT de prueba DPoP, lo firma criptográficamente con su clave privada e incluye el JWT de prueba DPoP en el encabezado HTTP DPoP de cada solicitud en la que se usa el token de acceso asociado.

La siguiente tabla describe cómo se emiten los tokens de acceso y si tienen restricción del remitente en función de varios parámetros de solicitud del cliente y de las configuraciones del servidor de recursos de Auth0:

Tipo de audiencia solicitada	¿El cliente requiere PoP?	¿El cliente envió una prueba de posesión (PoP)?	Política del servidor de recursos de Auth0: None	Política del servidor de recursos de Auth0: Allowed (No obligatoria)	Política del servidor de recursos de Auth0: Required
Solo Userinfo	No	No	Emitido, sin restricción del remitente	N/A	N/A
Solo Userinfo	No	Sí	Emitido, con restricción del remitente	N/A	N/A
Solo Userinfo	Sí	No	No emitido	N/A	N/A
Solo Userinfo	Sí	Sí	Emitido, con restricción del remitente	N/A	N/A
Audiencia personalizada (puede contener Userinfo)	No	No	Emitido, sin restricción del remitente	Emitido, sin restricción del remitente	No emitido
Audiencia personalizada (puede contener Userinfo)	No	Sí	Emitido, sin restricción del remitente	Emitido, con restricción del remitente	Emitido, con restricción del remitente
Audiencia personalizada (puede contener Userinfo)	Sí	No	No emitido	No emitido	No emitido
Audiencia personalizada (puede contener Userinfo)	Sí	Sí	No emitido	Emitido, con restricción del remitente	Emitido, con restricción del remitente

​

Configurar Sender Constraining para una aplicación cliente

Cuando exiges Sender Constraining para una aplicación cliente, los tokens de acceso quedan restringidos a esa aplicación. Auth0 verifica las solicitudes para garantizar que solo la aplicación que solicitó el token pueda usarlo para acceder al recurso asociado.

Una vez que configures una aplicación cliente para exigir Sender Constraining, puedes establecer el método de Sender Constraining, ya sea mTLS o DPoP, al configurar tu servidor de recursos.

Puedes configurar Sender Constraining para una aplicación cliente con el Auth0 Dashboard o la Management API.

Auth0 Dashboard

1. Ve a Dashboard > Applications > Applications. Selecciona la aplicación que quieres configurar.
2. En Settings, desplázate hasta Token Sender-Constraining.
3. Activa Require Sender Constraining. Desactíalo para quitar el requisito de Sender Constraining de la aplicación.

Management API

Para configurar un cliente para Sender Constraining, usa la Management API.

Para exigir Sender Constraining para un cliente, envía una solicitud PATCH para actualizar la configuración del cliente. Establece el parámetro require_proof_of_possession en true.

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/clients/{YOUR_CLIENT_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-d '{"require_proof_of_possession": true}'

Para quitar el requisito de Sender Constraining, establece el parámetro require_proof_of_possession en false.

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/clients/{YOUR_CLIENT_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-d '{"require_proof_of_possession": false}'

​

Configurar la restricción del remitente para un servidor de recursos

Los tokens de acceso emitidos por Auth0 pueden quedar restringidos al remitente (es decir, la aplicación cliente) que necesita acceder a las API de un servidor de recursos.

Puede configurar la restricción del remitente para un servidor de recursos con el Auth0 Dashboard o la Management API.

Auth0 Dashboard

Para habilitar Token Binding o Sender Constraining, configure API Settings de su API.

1. Vaya a Auth0 Dashboard > Applications > APIs.

2. Seleccione la API que desea configurar.

3. En la pestaña Settings, busque la sección Token Sender-Constraining.

4. Configure lo siguiente:

   1. Método de Sender Constraining:

      1. None: No habilite ningún método de Sender Constraining para su servidor de recursos.
      2. mTLS: Habilite mTLS como método de Sender Constraining para su servidor de recursos.
      3. DPoP: Habilite DPoP como método de Sender Constraining para su servidor de recursos.

   2. Require Token Sender Constraining: Seleccione qué política de Sender Constraining se aplica a esta API:

      1. Always: Requiera Sender Constraining para todas las aplicaciones. Esta es la única opción disponible al usar mTLS.
      2. For Public Applications: Requiera Sender Constraining solo para aplicaciones públicas. Esta opción no está disponible al usar mTLS.
      3. Never: No se requiere Sender Constraining.

Management API

Para habilitar Sender Constraining con la Management API, envíe una solicitud PATCH para actualizar el servidor de recursos. Establezca los parámetros del objeto proof_of_possession de la siguiente manera:

Parámetro	Descripción
mechanism	Establece el método de Sender Constraining: none, mtls o dpop.
required	Obligatorio. Cuando se establece en true, los tokens de acceso emitidos a una aplicación para esta API estarán restringidos a esa aplicación. Use required_for para especificar a qué tipos de aplicación se aplica este requisito. Cuando se establece en false, no se requiere Sender Constraining.
required_for	Filtra qué tipos de aplicación requieren Sender Constraining cuando required es true: all_clients (todas las aplicaciones) o public_clients (solo aplicaciones públicas). El valor predeterminado es all_clients si no se especifica. Al usar mTLS, solo all_clients es válido.

La siguiente muestra de código es un ejemplo de cuerpo de solicitud que configura un servidor de recursos para Sender Constraining con mTLS. Como mTLS solo admite all_clients para required_for (que es el valor predeterminado), no es necesario especificarlo:

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
  "proof_of_possession": {
    "mechanism": "mtls",
    "required": true
  }
}'

La siguiente muestra de código es un ejemplo de cuerpo de solicitud que configura un servidor de recursos para Sender Constraining con DPoP, requerido solo para aplicaciones públicas:

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
  "proof_of_possession": {
    "mechanism": "dpop",
    "required": true,
    "required_for": "public_clients"
  }
}'

La siguiente muestra de código configura Sender Constraining con DPoP como obligatorio para todas las aplicaciones. Como all_clients es el valor predeterminado, required_for puede omitirse:

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
  "proof_of_possession": {
    "mechanism": "dpop",
    "required": true
  }
}'

La siguiente muestra de código deshabilita Sender Constraining para un servidor de recursos (equivalente a seleccionar “Never” en el Dashboard):

curl -L -X PATCH 'https://{YOUR_DOMAIN}/api/v2/resource-servers/{YOUR_RESOURCE_SERVER_ID}' \
-H 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
  "proof_of_possession": null 
}'