Pin JWT Verification Keys
Keep a JWT header from selecting an arbitrary verification key, URL, or algorithm outside the server's trusted issuer policy.
A JWT header contains fields such as a key identifier and algorithm. The sender controls that header. It can help select among keys already trusted by the application, but it must not choose an arbitrary verification URL, public key, or algorithm. The trust anchor comes from server configuration and a verified issuer.
OWASP's JWT guidance describes token validation pitfalls. Build an explicit key-selection contract before using a convenience library. Review how it handles unknown kid values, key-set refresh, algorithm changes, and embedded key URLs.
Key-selection contract
| Input | Safe handling |
|---|---|
kid matches configured issuer key | Select that key after issuer binding |
Unknown kid | Reject or refresh trusted key set once |
| Token supplies key URL | Ignore or reject; never fetch it as authority |
| Algorithm differs from configured set | Reject |
| Key rotation overlaps | Accept only provider-published keys in window |
| Key set unavailable | Fail closed under stated cache policy |
Do not hard-code one key forever if the provider rotates keys, but do pin the issuer and metadata endpoint that may supply replacements. A stale-key cache needs a bounded lifetime and a safe refresh path. A token's jku or similar header must not become a network fetch to an untrusted host.
Header manipulation test
In an owned fixture, issue one valid token from the configured issuer. Then alter only the header: change the key ID, algorithm, and key URL in separate cases. Each manipulated token should fail before reaching the protected handler. Rotate the trusted key set in the fixture and confirm a token signed by the new published key works during the intended overlap.
Capture the key identifier and decision, not the token. Check proxy and application layers if both parse JWTs. A gateway accepting a token under one key policy while the app uses another can create inconsistent behavior. After signature and claim validation, still check the caller's current role and resource ownership. A well-verified token can request an unauthorized object.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.