Saltar al contenido principal
Para usar las funciones de Highly Regulated Identity, debe contar con un Enterprise Plan con el complemento Highly Regulated Identity. Consulte Auth0 Pricing para obtener más información.
La restricción del remitente es un mecanismo de seguridad de que vincula criptográficamente los tokens de acceso y los con la aplicación cliente que los solicitó. Esto garantiza que solo el cliente legítimo que obtuvo el 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 para su aplicación cliente y su en Auth0.
  • Asegurarse de que su aplicación cliente sea un , 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 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 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: 
{
  "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:
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 , 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.
  • 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