JWT And Mutual TLS Client Authentication In Released ProAuth

On this page

A server application needs to prove which client it is before receiving tokens. Choosing that proof affects key rotation, ingress configuration and the API’s token-validation work.

ProAuth shipped JWT-based and mutual TLS client authentication in 3.0.0. This follow-up to the June preview describes the client-authentication and token-binding choices shipped in ProAuth 3.0.

Choose the proof your team can operate

Method	Client proof	Operational responsibility
private_key_jwt	Signed assertion from an asymmetric client key	Protect private keys and register public validation keys
client_secret_jwt	Assertion signed with a shared client secret	Distribute and rotate the shared secret securely
tls_client_auth	TLS client certificate validated against configured identity metadata	Manage certificate trust, matching and renewal
self_signed_tls_client_auth	TLS client certificate whose public key matches registered keys	Register keys and plan overlap during rotation

JWT authentication is documented in the JWT client authentication guide; certificate methods are covered by the mTLS guide. A JWT assertion is not the same artifact as a JWT access token, and client_secret_jwt is not asymmetric authentication.

Separate client authentication from token binding

Client authentication answers which registered application is making a token request. Sender constraint answers whether the caller presenting a token also possesses its associated key or certificate.

flowchart TD
    Request[Confidential client requests a token] --> Auth[ProAuth validates registered client authentication]
    Auth --> Binding[Apply configured DPoP or certificate binding]
    Binding --> Token[Issue access token]
    Token --> API[Resource server checks token and required possession proof]

With certificate-bound access tokens, the resource server compares the presented certificate’s SHA-256 thumbprint with cnf.x5t#S256 from the token or introspection response. Trusting a token signature without checking the certificate does not enforce that binding.

ProAuth’s mTLS documentation distinguishes token-endpoint-issued certificate-bound access tokens from refresh tokens, which are not certificate-bound. An mTLS client still authenticates with its configured certificate on refresh. Keep those statements separate in architecture reviews.

Ingress is part of the mTLS design

Direct TLS certificates and forwarded certificate headers have different trust boundaries. ProAuth disables certificate forwarding by default. Where ingress terminates mutual TLS, explicitly configure the trusted proxy addresses or networks, strip untrusted incoming certificate headers and let the trusted proxy supply the validated certificate.

An arbitrary forwarded header is not evidence of possession. Include a spoofed-header test in the deployment review, along with certificate renewal and overlap. RFC 8705 defines OAuth mutual TLS authentication and certificate-bound access tokens.

Register the method on both sides

Make the application and ProAuth registration agree on the intended authentication method. PKCE, request signatures and sender-constrained access tokens have different jobs from confidential-client authentication. Test PAR as well as token redemption where the application uses both endpoints.

Include the actual client library in the acceptance test. Check the method it sends, the keys or certificates it uses, and behavior during rotation. The 3.0 release notes establish the supported client-authentication capabilities; use the linked configuration guides for the individual methods.

Choose the method with the clearest ownership: who provisions keys, who rotates them, who owns the proxy trust boundary, and who verifies possession at the API. A stronger proof is useful only when its full lifecycle is maintained.