Token Binding

Token binding (also known as sender constraining) enforces that only the application that requested an access token can utilize the token to access the associated resource. Highly Regulated Identity provides token binding capabilities through Mutual-TLS Client Certificate-Bound Access Tokens, also known as mTLS Token Binding.

When mutual TLS is used by the application to request an access token and the application is configured accordingly, the authorization server binds the client certificate to the issued access token. It does so by including the confirmation claim (cnf)  in the access token payload which contains a hash that represents the thumbprint of the client certificate. 

Here is an example of the payload of a certificate-bound access token:

{
  "iss": "https://server.example.com",
  "sub": "ty.webb@example.com",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf":{
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

mTLS Token Binding is supported only for confidential clients.

The resource server is responsible for verifying that the client certificate sent in the request has the same thumbprint as the one included in the access token. To verify that the application is authorized to use the certificate-bound access token, the resource server must generate the thumbprint of the client certificate used in the request and compare it to the one present in the cnf claim. For more information on the format of the cnf claim and how to generate the thumbprint of a certificate, see RFC 8705’s section on the 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 must reject the request using an HTTP 401 status code and an invalid_token error code.

To learn how to configure a client to support Token Binding, see Enable Token Binding.

• Configure mTLS Authentication