kid (Key ID) Header Parameter in a JWT

Rotation is why it exists. An issuer publishes the new public key alongside the old one, starts signing with the new key, and keeps the old one published until every token signed with it has expired. Verifiers pick the right entry by matching kid against the key set they fetched, so nothing breaks in the window where both keys are live. Without kid the verifier has to try each key in turn, which works but tells you nothing when it fails.

The value is opaque and issuers choose their own convention: a date, a random string, a thumbprint of the key. What matters is that it identifies an entry in a set the verifier already has, and that a kid the verifier does not recognize means fetch the key set again, once, with a rate limit. Refetching on every unknown kid turns a stream of forged tokens into a stream of requests to the issuer.

The unsafe pattern is treating kid as anything other than a lookup key. It has been used as a filename to read, as a fragment of a SQL query, and as a command argument, and each of those turns an attacker controlled string into path traversal, injection or worse. It arrives from outside, before verification, so it deserves the same handling as any other untrusted input: match it against known values and never let it name a resource.

The decoder shows kid in the decoded header and stops there. It does not fetch a key set, resolve the identifier or use it to select anything, because verification here is done with material you paste in. That makes it a safe place to read a header from an unfamiliar token: nothing in that header causes a request to anywhere, and nothing is uploaded.