Token Binding

Token Binding, or sender constraining, enables the binding of access tokens to cryptographic keys, such as a private key. It enforces that only the application that requested the access token can use it to access the associated resource, thus mitigating token theft and replay attacks.

Highly Regulated Identity provides token binding capabilities through Mutual-TLS Client Certificate-Bound Access Tokens, also known as mTLS Token Binding. To learn how to configure a client to support Token Binding, see Enable Token Binding.

After configuring your application for mTLS, your application can use mutual TLS to request an access token. The authorization server binds the client certificate to the issued access token by including the confirmation claim (cnf) in the access token payload. The cnf contains a hash representing the thumbprint of the client certificate.

The following code sample represents 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"
  }
}

When mTLS Token Binding is enabled, access and refresh tokens are constrained to the application that requested them (i.e. the “sender” application). 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/refresh token, otherwise known as proof-of-possession verification.

To verify that the application is authorized to use the certificate-bound access/refresh token, the resource server must generate the thumbprint of the client certificate used in the request and compare it to the thumbprint 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 application does not send the client certificate in the request, 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.

The following table describes whether issued tokens are sender-constrained based on the mTLS configuration for the application (OAuth client) and the API (OAuth resource server). The table covers the following scenarios:

• The type of audience that was requested: userinfo only or a custom audience that may include userinfo. 

• Whether sender constraining is required by the client.

• Whether sender constraining is configured for the resource server:

  • none: Sender constraining has not been configured for the resource server. 

  • allowed: Sender constraining has been configured for the resource server by setting mTLS as the sender-constraining method.

  • required: Sender constraining is required for the resource server, meaning that access tokens must be sender-constrained to an application. Requires a sender-constraining method. 

• Whether the client application sent a Proof-of-Possession assertion in the token request.

• Configure mTLS Authentication