Besides alg, what fields can appear in a JWT's JOSE header, and what does typ mean?

## What the header is for The first segment of a JWT is the JOSE header: metadata telling the recipient how to process the rest. It answers "which algorithm?", "which key?", "what kind of thing is this?" — never "who is the user?", which is the payload's job. Keeping that line clean matters: application data in the header is a smell, and header parameters treated as trusted input are a vulnerability. ## typ — the media type of the whole token `typ` declares the media type of the complete JWT. The historical convention is the value `"JWT"`, and it is optional — plenty of tokens omit it. The modern, better practice is **explicit typing**: giving each kind of token a distinct media type so a verifier can reject a token that is structurally valid but was minted for another purpose. The OAuth access-token profile, for example, specifies `typ` of `at+jwt`. Without explicit typing, a service that accepts "any token this issuer signed" can be handed an ID token, a refresh artefact or an internal service token and treat it as an access token, because all of them verify. A detail worth stating: the media-type prefix `application/` may be omitted in `typ`, which is why you see the short forms. ## cty — the type of the payload `cty` describes what the payload contains, and it is only needed when the payload is *not* a plain claims set. Its standard use is nesting: when a JWT is signed and then encrypted (or otherwise wrapped), the inner token becomes the outer token's payload, and the outer header sets `cty` to `"JWT"` so the recipient knows to run the decoded payload through JWT processing again rather than parsing it as claims. ## kid — which key `kid` is a key identifier: an opaque string the issuer chooses so that a verifier holding several keys can select the right one instead of trying each. It is a *hint*, and that word is load-bearing — it is attacker-supplied text that must be used as a lookup into a trusted set of keys, never as anything that touches a filesystem, a URL or a query. ## crit — extensions that must be understood `crit` is an array naming header parameters that the recipient is required to understand. If a verifier does not implement one of them, it must reject the token rather than ignore the parameter. This exists because JSON's tolerance for unknown members would otherwise let a security-relevant extension be silently skipped. It is rare in practice, but knowing what it means demonstrates you have read the header specification rather than guessed. ## Other parameters The JOSE specification also defines parameters that carry or point at keys and certificates — an embedded public key, a URL to a key set, certificate chains and thumbprints. Their existence is worth knowing; whether a verifier should ever act on them is a separate, sharper question. ## The header is signed, but not trusted Two statements that sound contradictory and are both true. The encoded header is part of the signing input, so once verification succeeds you know the header is exactly what the issuer wrote. But *before* verification, every field in it — including `alg` and `kid` — is text supplied by whoever sent the token. The correct posture is therefore to decide the acceptable algorithms and the key set from your own configuration, and to use the header only to select among choices you already trust. ## What interviewers listen for Naming `typ`, `cty` and `kid` with accurate meanings, not swapping `typ` and `cty`; understanding explicit typing as a way to stop cross-purpose token reuse; and articulating the signed-but-not-yet-trusted status of header values.