Restricción del remitente

Aprenda a aplicar la restricción del remitente a los tokens en Auth0.

La restricción del remitente es un mecanismo de seguridad de OAuth 2.0 y OpenID Connect (OIDC) que vincula criptográficamente los tokens de acceso y los tokens de actualización a la aplicación que los solicitó, lo que evita el robo y el uso indebido de tokens.

Tradicionalmente, los tokens de acceso 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 servidor de recursos (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:

Atributo	mTLS	DPoP
Capa de operación	Capa de transporte (TLS/SSL)	Capa de aplicación (encabezados HTTP)
Criptografía	Uso de infraestructura de clave pública (certificados X.509)	Uso de claves asimétricas (pares de claves generados por el cliente)
Prueba de posesión	Negociación TLS y validación de certificados	Prueba DPoP (JWT firmado en el encabezado HTTP para cada solicitud)
Tipo de cliente	Clientes confidenciales	Clientes públicos (SPA, aplicaciones móviles)

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:

Lea	Para aprender
Restricción del remitente con mTLS	Cómo funciona restricción del remitente con mTLS en Auth0, paso a paso.
Demostración de prueba de posesión (DPoP)	Cómo funciona DPoP en Auth0, paso a paso.
Configurar la restricción del remitente	Cómo configurar restricción del remitente para una aplicación cliente y un servidor de recursos en Auth0.

​

Más información

• Restricción del remitente con mTLS
• Demostración de prueba de posesión (DPoP)
• Configurar la restricción del remitente