> ## 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.
> Descripción general de cómo configurar la restricción del remitente para tu Tenant de Auth0.
# Configurar la restricción del remitente
[La restricción del remitente](/es/docs/secure/sender-constraining) 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](#configure-sender-constraining-for-a-client-application)
* [Configurar la restricción del remitente para un servidor de recursos](#configure-sender-constraining-for-a-resource-server)
## 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`](https://auth0.com/docs/api/authentication/user-profile/get-user-info), 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.
1. Ve a [Dashboard > Applications > Applications](https://manage.auth0.com/#/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.
Para configurar un cliente para Sender Constraining, usa la [Management API](https://auth0.com/docs/api/management/v2).
Para exigir Sender Constraining para un cliente, envía una solicitud PATCH para [actualizar la configuración del cliente](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id). Establece el parámetro `require_proof_of_possession` en `true`.
```bash lines theme={null}
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`.
```bash lines theme={null}
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.
Para habilitar Token Binding o Sender Constraining, configure **API Settings** de su API.
1. Vaya a [Auth0 Dashboard > Applications > APIs](https://manage.auth0.com/#/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.
Para habilitar Sender Constraining con la Management API, envíe una solicitud PATCH para [actualizar el servidor de recursos](https://auth0.com/docs/api/management/v2/resource-servers/patch-resource-servers-by-id). 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:
```bash lines theme={null}
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:
```bash lines theme={null}
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:
```bash lines theme={null}
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):
```bash lines theme={null}
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
}'
```