Autenticación con mTLS

Aprenda a autenticar un cliente mediante 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 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 y DPoP, 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 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://<custom-domain>/.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:

{
  ...
  "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:

{
  ...
  "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:

{
  ...
  "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 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.

​

Más información

• Configurar la autenticación mediante mTLS