Sender constraining tokens using Demonstrating Proof-of-Possession (DPoP) is currently in Early Access. To request access to this feature, contact your Auth0 representative.
Sender constraining is an and Connect (OIDC) security mechanism that cryptographically binds access and to the application that requested them, preventing token theft and misuse. Traditionally, OAuth 2.0 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 (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.

​
How it works

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.

​
mTLS vs. DPoP

The following table summarizes the high-level differences between mTLS and DPoP for sender constraining tokens:
AttributemTLSDPoP
Layer of operationTransport layer (TLS/SSL)Application layer (HTTP headers)
CryptographyUsing Public Key Infrastructure (X.509 Certificates)Using asymmetric keys (Client-generated key pairs)
Proof of PossessionTLS handshake and certificate validationDPoP Proof (signed JWT in HTTP header for each request)
Client typeConfidential clientsPublic clients (SPAs, mobile apps)
To learn more, read mTLS Sender Constraining and Demonstrating Proof-of-Possession (DPoP).

​
Get started

To get started with Sender Constraining at Auth0, read the following:
ReadTo learn
mTLS Sender ConstrainingHow mTLS sender constraining works in Auth0, step by step.
Demonstrating Proof-of-Possession (DPoP)How DPoP works in Auth0, step by step.
Configure Sender ConstrainingHow to configure sender constraining for a client application and resource server in Auth0.

​
Learn more