Add support for certificate bound access tokens (e.g., RFC8705)

[alegacy]

Is there any interest in adding support for verifying certificate bound access tokens (e.g., RFC8705)? We have interest in this feature to enable better support for operating in an mTLS environments and ensuring that tokens are only used by the client whom was issued the token.

More information is available in the RFC, but a very brief description is that the authorization server should only accepts token requests from verified and authorized mTLS clients. It then inserts a claim into the token that contains the SHA256 fingerprint of the client's certificate. Resource servers are expected to reject the token if the embedded fingerprint claim does not match the fingerprint of the client making the API request.

{
  "exp": 1739280596,
  "iat": 1739279696,
  "jti": "f74b4f39-7dae-4de8-9dc5-cc36a9c78bf4",
  "iss": "https://keycloak.example.com/realms/example",
  "aud": "example-client",
...
  "cnf": {
    "x5t#S256": "S2ArY2E4qD_l5lCuMhLh50DCxjVJmNFJbLI2RRzigDz"
  },
...
  "scope": "openid profile",
}

This requires that the client certificate information be available to the token verification mechanism.

1. When the SSL is terminated directly on the server that's relatively straightforward.
2. When SSL is terminated at a reverse proxy in front of the server then it is expected that the client certificate information should be carried in an HTTP header. The official recommended approach is with RFC9404, but different proxies have their own approach that predates the RFC (e.g., HA Proxy uses x-ssl-client-der to contain the DER encoded client certificate).

[alegacy]

I guess the first question is whether that type of functionality is better left to the caller to access the claims directly and do its own verification of the client certificate.