jwk (JSON Web Key) Header Parameter in a JWT

The failure is a circular one. If the verifier takes the key from the token and uses it to check the token's signature, then anyone can generate a key pair, sign whatever claims they like, embed the matching public key, and pass. The signature is genuine and completely meaningless, because it proves only that whoever wrote the claims also owns a key they made a moment earlier.

Real libraries have shipped this behaviour, honouring an embedded key by default because RFC 7515 defines the parameter and the code path looked like completeness. The lesson is not that jwk is broken but that a key has to come from somewhere the verifier already trusts, and a field inside the document being verified is by definition not such a place.

There is a correct use, and it looks different. In DPoP the client sends a proof token carrying its public key in jwk, and the resource server checks that the thumbprint of that key matches the jkt value inside the cnf claim of the access token, which was signed by the authorization server. The embedded key is accepted because a trusted party committed to it in advance, not because it was present.

The decoder shows a jwk header as decoded JSON so you can read the key type, curve or modulus and the key identifier. It will not use it: verification here takes a secret or a PEM public key that you supply. That mirrors what a service should do, and it means inspecting a suspicious token cannot cause the tool to trust anything the token brought with it.