2026-09-21 · 6 min read · Rahul Chitturi
- jwk
- jwt
- security
A JSON Web Key can carry use metadata for a broad purpose and key_ops metadata for specific operations. A library may reject a key when those values conflict with each other, the requested operation, the algorithm, or local policy.
Selecting a key by kid alone is insufficient. Duplicate identifiers, stale caches, mixed signing and encryption sets, and rotation overlap can all expose a plausible but unsuitable key.
Trace the selection decision
Record the trusted issuer and JWKS URL, token purpose, kid, algorithm, key type, curve or parameters, use, key_ops, and the local allowlist. Explain why each candidate was accepted or filtered without logging private material or bearer tokens.
- Require the key type to support the requested algorithm.
- Treat metadata conflicts as configuration errors.
- Keep verification and signing operations distinct.
- Constrain remote key locations through trusted issuer configuration.
Separate hints from authorization
Key metadata helps constrain operations, but it does not establish issuer trust or grant application authorization. Signature verification still needs an expected issuer, audience, algorithm policy, claims checks, and a trusted key-discovery path.
Define how missing use or key_ops is handled by your profile. Avoid silently broadening permissions merely because one producer omits optional metadata.
Test rotation and ambiguity
Use Flashman's JSON formatter for synthetic JWKS documents, JWT decoder for disposable headers, Base64 tool for public key fields, and diff for metadata changes. Use reviewed libraries for actual cryptographic decisions.
Test conflicting metadata, missing fields, duplicate kid values, wrong key types, algorithm mismatch, signing versus encryption keys, cache refresh, rotation overlap, revoked keys, malformed JWKs, and unsupported operations.