Skip to main content
La restricción del remitente es un mecanismo de seguridad de y Connect (OIDC) que vincula criptográficamente los tokens de acceso y los a la aplicación que los solicitó, lo que evita el robo y el uso indebido de tokens. Tradicionalmente, los de OAuth 2.0 son tokens al portador, lo que significa que quien “porta” o posee el token puede usarlo. Si un token al portador se roba o se filtra, un atacante puede presentarlo a un (API) y obtener acceso no autorizado suplantando a la aplicación cliente o al usuario legítimos. La restricción del remitente garantiza que la aplicación cliente que presenta el token de acceso a un servidor de recursos sea la propietaria legítima del token de acceso. Si la aplicación cliente no es la propietaria legítima del token de acceso, el servidor de recursos rechaza la solicitud a la API.

​
Cómo funciona

Puede implementar la restricción del remitente de una de estas dos maneras:
  • Vinculación de certificados mediante Mutual TLS (mTLS) en la capa de transporte:
    • Mecanismo: Cuando la aplicación cliente solicita un token de acceso al Servidor de autorización de Auth0, establece una conexión Mutual TLS (mTLS), en la que tanto la aplicación cliente como el servidor presentan y verifican mutuamente sus certificados X.509.
    • Vinculación: El Servidor de autorización de Auth0 incluye una claim de confirmación (cnf) con la huella digital del certificado de la aplicación cliente directamente en el token de acceso emitido.
    • Prueba de posesión: Cuando la aplicación cliente usa el token de acceso vinculado a mTLS para acceder a un servidor de recursos, debe volver a establecer una conexión mTLS con el mismo certificado. El servidor de recursos verifica que el certificado presentado por la aplicación cliente coincida con el vinculado al token de acceso. Si no coinciden, el servidor de recursos rechaza la solicitud.
    • Ventaja: Incluso si un atacante roba el token de acceso, no podrá usarlo porque no tendrá la clave privada ni el certificado correspondientes necesarios para establecer la conexión mTLS correcta. La restricción del remitente con mTLS suele usarse con clientes confidenciales, como las aplicaciones del lado del servidor, que pueden almacenar y gestionar de forma segura certificados X.509 y sus claves privadas.
  • Demostración de prueba de posesión (DPoP) en la capa de aplicación:
    • Mecanismo: DPoP funciona en la capa de aplicación y no requiere mTLS. En su lugar, la aplicación cliente genera su propio par de claves criptográficas (clave privada y clave pública).
    • Vinculación: Al solicitar un token de acceso, la aplicación cliente crea un JSON Web Token (JWT) llamado DPoP Proof JWT. Este JWT de prueba contiene la clave pública del cliente y está firmado con su clave privada. La aplicación cliente envía el DPoP Proof JWT junto con la solicitud del token de acceso. El Servidor de autorización de Auth0 valida el DPoP Proof JWT y luego vincula el token de acceso emitido a la clave pública.
    • Prueba de posesión: Cuando la aplicación cliente usa el token de acceso vinculado a DPoP para llamar a un servidor de recursos, genera otro DPoP Proof JWT firmado con su clave privada para esa solicitud a la API. La aplicación cliente envía el DPoP Proof JWT en un encabezado junto con el token de acceso. El servidor de recursos verifica que el token de acceso esté vinculado a la clave pública del DPoP Proof JWT y que el propio DPoP Proof JWT haya sido firmado con la clave privada correspondiente mediante una claim de confirmación (cnf).
    • Ventaja: DPoP es más flexible que mTLS porque no requiere una infraestructura de clave pública. Puede utilizarse con varios tipos de clientes, incluidos clientes públicos como las SPA y las aplicaciones móviles.

​
mTLS vs. DPoP

La siguiente tabla resume las diferencias generales entre mTLS y DPoP para la restricción del remitente de tokens: Para obtener más información, consulte Restricción del remitente con mTLS y Demostración de prueba de posesión (DPoP).

​
Primeros pasos

Para empezar a usar restricción del remitente en Auth0, lea lo siguiente:

​
Más información