Set up Resource Server for Token Binding
Whenever mTLS Token Binding is enabled, resource servers must ensure that the binding is enforced. Resource servers that enforce Token Binding must request client TLS certificates and perform some of the same verifications as the authorization server.
The cnf claim of an access token is an indication that Token Binding of some sort must be enforced. For mTLS Token Binding, the cnf claim has the following form:
"cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}
In this example, x5t#S256 indicates this access token is bound to an mTLS client certificate with a thumbprint of A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0.
The resource server that receives a bound access token must verify that the client certificate sent in the request has a matching thumbprint (A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0 in our example). 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.
Unlike the authorization server (or customer edge), the resource server does not necessarily need to verify the entire certificate chain of the client certificate, only that the client certificate matches the one in the access token’s thumbprint. For more information on how the thumbprint is calculated, see RFC 8705’s section on JWT Certificate Thumbprint Confirmation Method.
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.
For more information, see RFC 8705’s sections on Token Binding and Resource Servers.