Configure Resource Server for Sender Constraining
To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to Auth0 Pricing for details.
When you enable Sender Constraining for an API, the resource server must enforce Sender Constraining whenever the client calls the resource server with a certificate-bound access token. The resource server does so by:
Requesting the client certificate from the established mTLS connection
Verifying that the client certificate’s thumbprint matches the thumbprint in the access token
To configure a resource server for Sender Constraining, see Enable Sender Constraining for a resource server.
Client certificate verification
Unlike the authorization server or customer edge, the resource server only needs to verify the thumbprint of the client certificate instead of its entire certificate chain. For mTLS Sender Constraining, the resource server examines the cnf claim of the access token:
"cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}Was this helpful?
In our example cnf claim, x5t#S256 indicates that the access token is bound to an mTLS client certificate with a thumbprint of A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0. To pass client certificate verification, the resource server must verify that the client certificate has a matching thumbprint of A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0. To learn more about how the thumbprint is calculated, read RFC 8705’s section on JWT Certificate Thumbprint Confirmation Method.
If the client certificate was not sent, or the thumbprint of the client certificate does not match, the resource server rejects the request using an HTTP 401 status code and an invalid_token error code. To learn more, read RFC 8705’s sections on Mutual-TLS Client Certificate-Bound Access Tokens and Resource Servers.
Resource servers that progressively migrate clients to use mTLS may wish to expose their API at two domains: one non-mTLS domain for non-mTLS clients and one mTLS-enabled domain for mTLS-capable clients. An alternative is to create an entirely separate mTLS-only resource server on an mTLS-enabled domain.
Configure Sender Constraining for a resource server in Auth0
Access tokens issued by Auth0 can be constrained to the sender (i.e. the client application) that needs to access APIs at a resource server.
Use the Auth0 Dashboard or Management API to enable Sender Constraining for a resource server.
To enable Token Binding or sender constraining, configure the API Settings of your API.
Navigate to Auth0 Dashboard > Applications > APIs.
Select the API you want to configure.
Under the Settings tab, find the Token Sender-Constraining section.
Configure the following:
Sender Constraining Method: None or mTLS.
Require Token Sender Constraining: all access tokens issued to an application for this API will be constrained to that application.
To enable Sender Constraining with the Management API, send a PATCH request to update the resource server. Set the parameters of the proof_of_posession object to the following:
| Parameter | Description |
|---|---|
mechanism |
Sets the sender-constraining method: none or mtls |
required |
When set to true, all access tokens issued to an application for this API will be constrained to that application. When set to false, sender constraining is not required for the application. |
The following code sample is an example request body that configures a resource server for mTLS Sender Constraining:
"proof_of_possession": {
"mechanism": "mtls",
"required": true
}Was this helpful?