Key representation
A JSON Web Key represents cryptographic key parameters. A JSON Web Key Set publishes one or more keys. A verifier uses trusted issuer configuration, permitted algorithms, key use, and often a key identifier to select a candidate verification key.
Trust the source
Bind the JWKS location to a trusted issuer or local configuration. Do not fetch a key URL supplied by an unverified token. Restrict algorithms and key types independently of the token header. Match key use and operation. Reject ambiguous duplicate identifiers and incompatible keys.
Rotate with overlap
Publish a new verification key before signing with it. Let verifiers refresh within a bounded cache period. Switch signing, retain the old public key only for still-valid tokens, then remove it. Define unknown-key refresh limits so attacker-selected identifiers cannot cause unbounded requests.
Failure and residual risk
Algorithm confusion, attacker-controlled key sources, reused identifiers, stale caches, premature removal, excessive overlap, and compromised issuer keys can accept or reject the wrong tokens. Key rotation does not revoke already issued tokens while their signatures and claims remain valid.
Pomerium boundary
Pomerium publishes keys for its signed identity assertions and uses provider keys for configured authentication flows. Applications that validate Pomerium assertions must trust the documented key source, restrict validation, and handle rotation. They still enforce local permission after signature validation.
Evaluation checklist
- Is the key set bound to an approved issuer or configuration?
- Are algorithms, key types, use, and operations restricted locally?
- Can unknown, duplicate, stale, and rotated key identifiers fail safely?
- Does rotation preserve valid overlap without indefinite old trust?
- Can key compromise trigger token, session, and credential response beyond key replacement?
