There are currently no plans to support the full mTLS spec. We are discussing DPoP (tracking issue) internally.

However, depending on your needs, there may be a workaround.

Since the client credentials grant depends on Entities, you can leverage this to inject a client certificate hash into an access token obtained through the client credentials grant.

How this works at a high level:

• Client Certificate Registration
  During onboarding, your customer (e.g., a bank) registers their client certificate. A hashed value of that certificate is securely stored in FusionAuth (entity.data). The hashing process is outlined in the RFC.
• Client Credentials Request
  When the bank requests an access token using the Client Credentials grant, a FusionAuth Lambda is invoked before the JWT is signed.
• Augment Custom Claims
  The Lambda code looks up the stored certificate hash and injects it as a claim in the JWT. For maximum compatibility with RFC 8705, it is recommended to add this hash to the cnf object in the JWT, like so:

"cnf":{
  "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}

• Accessing the Resource Server or API
  The customer presents both the access token and presents their client certificate when calling your API.
• Validation Flow
  Your API:
  • verifies the JWT signature
  • computes a hash of the presented client certificate
  • compares it to the x5t#S256 claim in the token
• Decision Logic
  If the hashes match, the request is bound to the correct client and access is granted to the protected resource.