Sender Constraining

Sender constraining is an OAuth 2.0 and OpenID Connect (OIDC) security mechanism that cryptographically binds access and refresh tokens to the application that requested them, preventing token theft and misuse.

Traditionally, OAuth 2.0 access tokens are bearer tokens, which means whoever “bears” or possesses the token can use it. If a bearer token is stolen or leaked, an attacker can present it to a resource server (API) and gain unauthorized access by impersonating the legitimate client application or user.

Sender constraining ensures that the client application presenting the access token to a resource server is the valid owner of the access token. If the client application is not the valid owner of the access token, then the resource server rejects the API request.

You can implement sender constraining in one of two ways:

• Mutual-TLS (mTLS) certificate binding in the transport layer:

  • Mechanism: When the client application requests an access token from the Auth0 Authorization Server, it establishes a mutual TLS (mTLS) connection, where both the client application and the server present and verify each other's X.509 certificates.

  • Binding: The Auth0 Authorization Server includes a confirmation (cnf) claim that includes the thumbprint of the client application's certificate directly within the issued access token.

  • Proof of Possession: When the client application uses the mTLS-bound access token to access a resource server, it must again establish an mTLS connection using the same certificate. The resource server verifies that the certificate presented by the client application matches the one bound to the access token. If they don't match, the resource server rejects the request.

  • Benefit: Even if an attacker steals the access token, they cannot use it because they won't possess the corresponding private key and certificate required to establish the correct mTLS connection. mTLS sender constraining is typically used by confidential clients such as server-side applications that can securely store and manage X.509 certificates and their private keys.

• Demonstrating Proof-of-Possession (DPoP) in the application layer:

  • Mechanism: DPoP operates at the application layer and doesn't require mTLS. Instead, the client application generates a cryptographic key pair (private/public key) for itself.

  • Binding: When requesting an access token, the client application creates a JSON Web Token (JWT) called a DPoP Proof JWT. This proof JWT contains the client's public key and is signed by the client's private key. The client application sends the DPoP Proof JWT along with the access token request. The Auth0 Authorization Server validates the DPoP Proof JWT and then binds the issued access token to the public key.

  • Proof of Possession: When the client application uses the DPoP-bound access token to call a resource server, it generates another DPoP Proof JWT signed with its private key for that API request. The client application sends the DPoP Proof JWT in a header alongside the access token. The resource server verifies that the access token is bound to the public key in the DPoP Proof JWT, and that the DPoP Proof JWT itself has been signed by the corresponding private key using a confirmation (cnf) claim.

  • Benefit: DPoP is more flexible than mTLS because it doesn't require a public key infrastructure. Various client types can use it, including public clients like SPAs and mobile applications.

The following table summarizes the high-level differences between mTLS and DPoP for sender constraining tokens:

To learn more, read mTLS Sender Constraining and Demonstrating Proof-of-Possession (DPoP).

To get started with Sender Constraining at Auth0, read the following: