> ## 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 autenticar un cliente mediante mTLS.
# Autenticación con mTLS
## mTLS en OAuth/OIDC
Los flujos predeterminados de OAuth/OIDC no siempre son seguros debido a los siguientes problemas:
* El uso de un Secreto del cliente compartido como forma de autenticación del cliente.
* La posibilidad de que un token de acceso sea utilizado por partes no autorizadas.
En 2020, el Internet Engineering Task Force (IETF) publicó en [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705) la autenticación de cliente Mutual-TLS (mTLS) para abordar estos problemas. Con la autenticación mTLS, el certificado de cliente con una clave privada actúa como un Secreto del cliente en un flujo OAuth/OIDC para verificar la identidad del cliente. Si un cliente ya está autenticado en la capa de red, no se necesita un Secreto del cliente en la capa de aplicación. Además, los certificados de cliente pueden usarse con varios servidores para demostrar la identidad de un cliente ante un servidor de recursos. Ten en cuenta que existen otros enfoques para resolver los problemas anteriores, concretamente [Private Key JWT](/es/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) y [DPoP](https://datatracker.ietf.org/doc/html/rfc9449), respectivamente.
Para proteger un flujo OAuth con mTLS, los clientes envían un certificado mTLS al punto de terminación TLS en el extremo de la red del cliente mientras se establece la conexión TLS. Antes de que el servidor de autorización procese la solicitud, primero debe verificar el certificado mTLS del cliente.
De forma opcional, mTLS también puede usarse para garantizar que un token de acceso solo sea utilizado por la parte prevista, lo que se conoce como Sender Constraining o Token Binding. Cuando el cliente llama al endpoint `/oauth/token` en el servidor de autorización mediante una conexión mTLS, el token de acceso resultante contiene información que el servidor de recursos utiliza para verificar que el certificado TLS del cliente coincide con el del token de acceso.
**Nota**: la autenticación de cliente mTLS y el Token Binding de mTLS pueden utilizarse de forma independiente. La autenticación de cliente mTLS puede utilizarse sin Token Binding de mTLS, y el Token Binding de mTLS puede utilizarse con otras formas de autenticación del cliente, como Secreto del cliente o Private Key JWT. Incluso si se utilizan otras formas de autenticación del cliente, el cliente sigue enviando el certificado de cliente al servidor de autorización para el Token Binding de mTLS.
## mTLS en Auth0
mTLS para Auth0 se basa en [dominios personalizados](/es/docs/customize/custom-domains) y aprovecha la infraestructura mTLS existente del cliente para realizar el aprovisionamiento y la verificación de certificados.
Las llamadas autenticadas de clientes a Auth0 que normalmente requieren un Secreto del cliente se envían primero al perímetro del cliente. Esto ya ocurre para los dominios personalizados que usan certificados administrados por el cliente. El perímetro del cliente realiza el handshake de mTLS con el cliente y valida el certificado del cliente. Una vez verificado el certificado del cliente, la solicitud se reenvía al dominio de borde del inquilino en Auth0, incluyendo el certificado del cliente validado en un encabezado HTTP junto con la `cname-api-key` correcta, según la funcionalidad de dominios personalizados.
## Llamar al servidor de autorización
Dado que mTLS sirve tanto para la autenticación del cliente como para la vinculación del token de acceso, el cliente debe saber si estas funciones están habilitadas en el servidor de autorización. Además, los endpoints mTLS y no mTLS de un servidor de autorización pueden estar expuestos en dominios diferentes.
Para obtener detalles de configuración sobre el servidor de autorización, el cliente envía una solicitud GET al endpoint de [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html): `https:///.well-known/openid-configuration`
Una respuesta satisfactoria devuelve el documento de descubrimiento de OIDC, o un objeto JSON que enumera las propiedades y los endpoints del servidor de autorización, incluidos los relacionados con mTLS.
Si la autenticación de cliente mediante mTLS está habilitada, el documento de descubrimiento de OIDC incluye la propiedad `token_endpoint_auth_methods_supported`, que contiene `tls_client_auth` o `self_signed_tls_client_auth`:
```json lines theme={null}
{
...
"token_endpoint_auth_methods_supported": ["tls_client_auth"]
...
}
```
Si el Token Binding de mTLS está habilitado, el documento de descubrimiento de OIDC establece la propiedad `tls_client_certificate_bound_access_tokens` en `true:`
```json lines theme={null}
{
...
"tls_client_certificate_bound_access_tokens": true
...
}
```
Los entornos que admiten alias de endpoints mTLS exponen una nueva propiedad, `mtls_endpoint_aliases`, que contiene una lista de endpoints compatibles con mTLS. Para los clientes que admiten mTLS, los endpoints que aparecen en `mtls_endpoint_aliases` tienen prioridad sobre los mismos endpoints expuestos fuera de `mtls_endpoint_aliases`.
En el siguiente ejemplo de código, la propiedad `token_endpoint` se expone dos veces. El endpoint que debe usarse para las llamadas mTLS aparece en `mtls_endpoint_aliases`, o bien `https://mtls.auth.bank.com/oauth/token`:
```json lines theme={null}
{
...
"mtls_endpoint_aliases": {
"token_endpoint": "https://mtls.auth.bank.com/oauth/token"
},
"token_endpoint": "https://auth.bank.com/oauth/token",
"pushed_authorization_request_endpoint": "https://auth.bank.com/oauth/par",
...
}
```
Si un endpoint no aparece en `mtls_endpoint_aliases`, use el mismo endpoint que figura fuera de `mtls_endpoint_aliases`. En el ejemplo anterior, `pushed_authorization_request_endpoint` no aparece en `mtls_endpoint_aliases`. En consecuencia, use `pushed_authorization_request_endpoint`, expuesto fuera de `mtls_endpoint_aliases`, o `https://auth.bank.com/oauth/par`.
Para obtener más información, consulte la [sección sobre alias de endpoint](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end) de la RFC 8705.
## Llamar al servidor de recursos
Una vez que un cliente recibe un token de acceso, puede acceder a recursos protegidos en un servidor de recursos. Si Token Binding de mTLS está habilitado, el servidor de autorización devuelve el documento de descubrimiento de OIDC que contiene la propiedad `tls_client_certificate_bound_access_tokens`.
Cuando el cliente llama al servidor de recursos con un token de acceso vinculado a mTLS, el servidor de recursos solicita un certificado mTLS del cliente durante el protocolo de enlace TLS. El servidor de recursos debe rechazar las solicitudes cuyo token de acceso no coincida con ese certificado de cliente, con un código de estado HTTP 401 y un código de error `invalid_token`. Para obtener más información, consulte [Configurar el servidor de recursos para la restricción del remitente](/es/docs/secure/sender-constraining/configure-sender-constraining/configure-resource-server-for-sender-constraining).
## Más información
* [Configurar la autenticación mediante mTLS](/es/docs/get-started/applications/configure-mtls)