flashman
← All guides

JWK use and key operations policy

Build a consistent JWK operation policy across use, key_ops, alg, key type, trusted discovery, rotation, and library behavior without weakening token validation.

2026-09-21 · 8 min read

  • jwk
  • jwt
  • security

JSON Web Keys can include use to indicate a broad public-key purpose and key_ops to enumerate specific operations. Other members such as alg, kty, crv, kid, and certificate data further describe or identify the key, while local policy decides whether it may be used.

These fields should narrow candidate keys, not replace issuer trust, algorithm allowlists, signature verification, or claims validation. A coherent profile defines how metadata is interpreted when fields are present, absent, or contradictory.

Define one operation vocabulary

List every operation the application performs, such as verifying signatures or decrypting content, then define acceptable key types, curves or parameters, algorithms, use values, and key_ops values for each operation.

  • Reject contradictory declared purposes.
  • Never infer a private-key operation from public material.
  • Keep signing and encryption key sets separable.
  • Treat unknown operations as unsupported.

Constrain discovery before key selection

Bind remote JWKS locations to trusted issuer configuration and enforce HTTPS, response size, key count, parsing, redirect, caching, and network-boundary policy. Do not follow arbitrary key URLs supplied by an untrusted token.

After discovery, filter candidates by operation policy, algorithm, and key shape before using kid to resolve identity. Duplicate identifiers or several equally suitable candidates should produce a controlled ambiguity error.

Plan omission and rotation behavior

Specifications can permit omitted metadata, but deployments often need a stricter profile. Decide whether missing use, key_ops, or alg is accepted, rejected, or constrained by trusted out-of-band configuration; do not let omission silently grant broader operations.

Cache refresh and rotation need overlap, bounded stale-key use, unknown-kid recovery, revocation response, and protection from attacker-triggered refresh storms. Record safe decision categories without tokens or private key values.

Test policy independently from cryptography

Use Flashman's JSON formatter for synthetic JWKS sets, JWT decoder for disposable headers, Base64 and hash tools for public vectors, and diff for rotation metadata. Perform real verification with reviewed cryptographic libraries.

Cover each allowed operation, conflicts, omissions, duplicate kid values, algorithm and key-type mismatch, malformed parameters, mixed signing and encryption sets, cache expiry, rotation overlap, unavailable discovery, revoked keys, and library upgrades.

Try these tools