> ## 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.
> Aprenda a restricción del remitente tokens al remitente mediante mTLS en Auth0.
# Vinculación al remitente con mTLS
Para usar las funciones de Highly Regulated Identity, debe contar con un Enterprise Plan con el complemento Highly Regulated Identity. Consulte [Auth0 Pricing](https://auth0.com/pricing/) para obtener más información.
La [restricción del remitente](/es/docs/secure/sender-constraining) es un mecanismo de seguridad de OAuth 2.0 que vincula criptográficamente los tokens de acceso y los tokens de actualización con la aplicación cliente que los solicitó. Esto garantiza que solo el cliente legítimo que obtuvo el token de acceso pueda usarlo para acceder a recursos protegidos, lo que proporciona una defensa sólida contra el robo de tokens y los ataques de repetición.
Los tokens de acceso vinculados a certificados de cliente Mutual-TLS (mTLS), o la restricción del remitente con mTLS, logran esta asociación aprovechando el certificado TLS del cliente. Con mTLS, el token de acceso del cliente queda vinculado a su certificado de cliente único, lo que hace que el token no pueda ser utilizado por ninguna otra parte.
## Requisitos previos
Para implementar restricción del remitente con mTLS, debe:
* Tener un plan Enterprise con el complemento Highly Regulated Identity para su inquilino de Auth0.
* [Configurar restricción del remitente](/es/docs/secure/sender-constraining/configure-sender-constraining) para su aplicación cliente y su servidor de recursos en Auth0.
* Asegurarse de que su aplicación cliente sea un cliente confidencial, ya que solo los clientes confidenciales admiten restricción del remitente con mTLS.
## Cómo funciona
En esta sección se describe el proceso para obtener y usar un token de acceso vinculado a mTLS.
## Fase 1: Solicitar un token de acceso vinculado a mTLS
### Paso 1: La aplicación cliente establece una conexión mTLS
* Antes de solicitar un token de acceso, la aplicación cliente inicia un handshake de TLS con el endpoint `/token` del Servidor de autorización de Auth0.
* Durante este handshake, la aplicación cliente presenta su certificado de cliente al Servidor de autorización de Auth0 como parte del proceso de autenticación TLS mutua.
### Paso 2: La aplicación cliente solicita un token de acceso
* La aplicación cliente envía una solicitud de token estándar de OAuth 2.0, por ejemplo, con `grant_type=client_credentials` o `authorization_code`, al endpoint `/token` del Servidor de autorización de Auth0.
* La solicitud de token no incluye ningún encabezado DPoP especial ni JWTs de prueba adicionales para mTLS. La prueba de posesión se obtiene directamente de la conexión mTLS.
### Paso 3: El Servidor de autorización de Auth0 procesa la solicitud y vincula el token
Cuando el Servidor de autorización de Auth0 recibe la solicitud de token a través de una conexión mTLS y el certificado del cliente se valida correctamente:
1. **Extrae el certificado:** El Servidor de autorización de Auth0 extrae el certificado del cliente usado en el handshake de mTLS.
2. **Calcula la huella digital:** El Servidor de autorización de Auth0 calcula un hash único (huella digital) del certificado del cliente.
3. **Vincula el token:** El Servidor de autorización de Auth0 vincula la huella digital de este certificado de cliente al token de acceso emitido incluyendo una reclamación de confirmación (`cnf`) en la carga útil del token de acceso.
* La reclamación `cnf` contiene el parámetro `x5t#S256`, que es la huella digital SHA-256 del certificado del cliente codificada en Base64url.
4. **Establece** `token_type`**:** El Servidor de autorización de Auth0 establece `token_type` en DPoP. Esto difiere de los tokens Bearer tradicionales e indica que el token está vinculado a una clave específica.
5. **Emite el token:** El Servidor de autorización de Auth0 emite el token de acceso con restricción por remitente mediante mTLS para su aplicación cliente.
El siguiente ejemplo de código muestra una carga útil de un token de acceso vinculado a un certificado mTLS:
```json lines theme={null}
{
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf": {
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}
}
```
En el ejemplo de token de acceso vinculado a un certificado mTLS, `x5t#S256` indica que el token de acceso está asociado a un certificado de cliente mTLS con la huella digital SHA-256 `bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2`.
## Fase 2: Llamar a una API con un token de acceso asociado a mTLS
### Paso 4: La aplicación cliente llama a la API
* Cuando su aplicación cliente necesite llamar a una API que aplica la restricción del remitente con mTLS, debe establecer una nueva conexión mTLS con el servidor de recursos.
* Durante este handshake de mTLS, la aplicación cliente vuelve a presentar el mismo certificado de cliente que se utilizó para obtener el token de acceso.
* Luego, la aplicación cliente incluye el token de acceso vinculado a mTLS en el encabezado Authorization de la solicitud a la API mediante el esquema de autenticación DPoP:
```http lines theme={null}
Authorization: DPoP {your_mtls_bound_access_token}
```
Aunque la RFC 8705 permite un esquema Bearer con tokens vinculados a mTLS, Auth0 recomienda usar DPoP para aplicar tokens de acceso vinculados a mTLS. Esto indica explícitamente al servidor de recursos que debe esperar un token vinculado criptográficamente.
### Paso 5: El servidor de recursos verifica el token y el certificado
Cuando el servidor de recursos recibe la solicitud a la API a través de una conexión mTLS:
1. **Solicita el certificado del cliente:** El servidor de recursos obtiene el certificado del cliente de la conexión mTLS establecida.
2. **Extrae el token y la reclamación `cnf`:** El servidor de recursos extrae el token de acceso del encabezado `Authorization` y decodifica su carga útil para encontrar la reclamación `cnf` (confirmación), en concreto el valor `x5t#S256` (la huella digital del certificado vinculado).
3. **Calcula la huella digital actual del certificado:** El servidor de recursos calcula la huella digital SHA-256 del certificado del cliente recibido en la conexión mTLS actual.
4. **Compara las huellas digitales (verificación de Proof-of-Possession):** El servidor de recursos compara la huella digital recién calculada con la huella digital `x5t#S256` de la reclamación `cnf` del token de acceso.
5. **Autoriza o rechaza la solicitud:**
* Si las huellas digitales coinciden y también se superan otras validaciones del token, como la expiración, la audiencia y el emisor, la solicitud se autoriza.
* Si no se envió el certificado del cliente o su huella digital no coincide con la de la reclamación `cnf`, el servidor de recursos rechaza la solicitud con un código de estado `HTTP 401 Unauthorized` y un código de error `invalid_token`.
Para entender cómo se calcula la huella digital y el formato de la reclamación `cnf`, consulta la RFC 8705: Mutual-TLS Client Certificate-Bound Access Tokens.
## Consideraciones importantes
Al implementar la restricción del remitente con mTLS, tenga en cuenta lo siguiente:
* **Solo para clientes confidenciales:** La restricción del remitente con mTLS está diseñada y solo es compatible con clientes confidenciales, como los servicios de backend, que pueden administrar certificados de cliente de forma segura y establecer conexiones mTLS. Los clientes públicos, como las SPA y las aplicaciones móviles, deben usar DPoP.
* **Administración de certificados:** La seguridad de su implementación de mTLS depende en gran medida de sus prácticas de administración de certificados, como la forma en que aprovisiona, administra y rota los certificados de cliente.
* **Requisitos de infraestructura:** Implementar mTLS requiere una infraestructura específica, incluidos proxies, balanceadores de carga y API capaces de terminar conexiones mTLS y transmitir la información del certificado de cliente a la aplicación o al servidor de recursos.
* **Aplicación en el servidor de recursos:** Cuando habilita la restricción del remitente con mTLS para una API en Auth0, el servidor de recursos debe realizar la verificación de la huella digital, como se describe en el [Paso 5](#step-5-resource-server-verifies-token-and-certificate).
* **Estrategias de migración:** Si está migrando clientes progresivamente para que usen mTLS, considere exponer su API en dos dominios: uno sin mTLS para los clientes existentes y otro habilitado para mTLS para los clientes compatibles con mTLS. Como alternativa, podría implementar lógica en un único dominio para diferenciar entre solicitudes con y sin mTLS.
* **Manejo de errores:** Implemente un manejo de errores sólido tanto en el cliente como en el servidor de recursos para gestionar adecuadamente los casos en que los certificados faltan, no son válidos o no coinciden.
## Más información
* [Configurar la restricción del remitente](/es/docs/secure/sender-constraining/configure-sender-constraining)