cnf (Confirmation) Claim in a JWT

A plain access token is a bearer credential: anyone who obtains a copy can use it until it expires. cnf changes the deal by naming a key inside the signed token. The resource server then requires the caller to demonstrate possession of the matching private key on every request, so a stolen token on its own is useless without the key that never travels with it.

Three shapes turn up in practice. RFC 7800 defines jwk, which embeds the public key, and kid, which references one. RFC 8705 uses x5t#S256 to hold the SHA-256 thumbprint of the client certificate used on the mutually authenticated connection. RFC 9449 uses jkt for the thumbprint of the DPoP key, and the client proves possession by signing a short lived proof for each request.

The claim is only as good as the enforcement. A resource server that reads cnf and does not verify the corresponding proof gets no protection whatsoever, and a client that is issued a constrained token but presents it as a plain bearer token will simply be refused. Both halves have to be deployed, which is why the claim is common in financial grade profiles and rare elsewhere.

The decoder shows cnf under Custom claims as JSON so you can see which confirmation method is in use and read the thumbprint or embedded key. It cannot check the proof, because that lives outside the token: a DPoP proof is a separate JWT sent in its own header, and an mTLS binding is a property of the connection. What it does verify, in your browser, is the access token's own signature.