Let configuration choose the algorithm
A validator should not accept whichever algorithm the token header requests. Configure the allowed algorithm family for the application and reject everything else. Mixing symmetric and asymmetric expectations around the same key material can create dangerous confusion.
Resolve keys only from trusted configuration or a pinned issuer metadata path. An attacker-controlled key URL in the token must never become a network instruction for the verifier.
A valid signature is not enough
Check issuer, audience, expiration, not-before time, and the claim set required for this exact token type. A signed ID token is not automatically an API access token, and a token issued for one service should not authorize another.
Use mutually exclusive validation rules for different token kinds. Explicit typing and separate key or audience configurations help prevent a token accepted in one context from being replayed in another.
- Reject missing critical claims instead of applying generous defaults.
- Use a small clock-skew allowance and record why it exists.
- Keep authorization decisions outside untrusted or loosely defined claims.
- Test malformed, expired, wrong-audience, and wrong-key tokens.
Key rotation is part of validation
Cache signing keys with a bounded lifetime and handle rotation without accepting an unbounded set forever. Unknown key ids should trigger a controlled refresh, not a request to arbitrary infrastructure.
Treat the validation function as a security boundary with a narrow, testable contract. If application code receives claims before that contract succeeds, the design is already too permissive.