JWKS and JWT verification: what identity teams need to know

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: JWKS and JWT verification fit together to support token trust, and key rotation, caching, and algorithm selection matter to that trust.

Why it matters: IAM teams need to treat JWKS as a verification control, not a trust guarantee, because poor token validation can undermine distributed authentication across APIs and applications.

Context

JWKS is a public key distribution mechanism for JWT verification, but it only solves one part of the trust problem. Identity teams still have to decide which issuer, audience, algorithm, and token lifetime rules are acceptable before a signed token is treated as valid.

For NHI and application authentication programmes, the governance issue is not whether keys can be published, but whether verifiers enforce the full control set around them. A correct signature proves origin, not fitness for use, so the operational risk sits in validation gaps and stale caching behaviour.

The article's core message is that distributed token verification becomes practical only when key rotation, endpoint integrity, and claim validation are managed together. That is a familiar pattern in identity security: the cryptography is necessary, but the policy layer decides whether the token should be trusted.

Key questions

Q: How should security teams validate JWTs after fetching keys from a JWKS endpoint?

A: Validate the signature first, then enforce issuer, audience, expiration, and not-before claims before the token reaches any privileged path. A correct JWKS only proves that a key is public and usable for verification. It does not prove the token was meant for your service, still active, or acceptable under your issuer policy.

Q: Why do JWKS refresh rules matter for authentication reliability?

A: Refresh rules matter because cached keys must stay fresh enough to support rotation, but not so loose that attackers can force repeated outbound fetches. Controlled refresh on kid miss preserves usability during key rollover while limiting abuse. Without that balance, token verification can become either brittle or noisy.

Q: What happens when services trust JWT signatures without checking claims?

A: They can accept a token that was genuinely signed but still wrong for the service, expired, or issued by the wrong authority. That turns cryptographic validity into an authorization bypass opportunity. The practical failure is not broken signing, but incomplete verification logic at the application boundary.

Q: What is the difference between JWKS caching and token lifetime controls?

A: JWKS caching governs how quickly verifiers see key changes, while token lifetime controls govern how long any token remains usable. Both need to be aligned. If caching is stale, rotation is delayed. If token lifetimes are too long, old signatures remain useful longer than the intended trust window.

Technical breakdown

How JWKS enables distributed JWT verification

A JWKS is a JSON document that publishes one or more public JWKs so resource servers can verify JWT signatures locally. The issuer keeps the private key secret and exposes the matching public key through a JWKS endpoint, usually referenced by OpenID Connect discovery. The verifier uses the token's kid header to select the right key, which makes verification stateless and avoids a callback on every request. That model works well for scale, but it only governs signature checking. It does not prove that the token was intended for this service, issued at the right time, or signed with an approved algorithm.

Practical implication: treat JWKS as a public-key lookup mechanism, then separately enforce issuer, audience, expiration, and algorithm checks.

Why key rotation needs overlapping keys and cache discipline

JWKS supports rotation because old and new public keys can coexist in the same set while in-flight tokens age out. That overlap is essential, since a token signed before rotation may still be valid after the new key is active. Caching improves performance, but the cache becomes part of the trust boundary. If a verifier never refreshes on kid miss, it may reject valid tokens after rotation. If it refreshes too aggressively, an attacker can force repeated fetches by sending tokens with unknown key IDs. The operational balance is controlled refresh, not unlimited retries.

Practical implication: cache JWKS responses, refresh on kid miss, and rate-limit refetches so rotation does not become an availability or abuse problem.

Why alg allowlists matter more than signature success

JWT verification is only sound when the verifier restricts which algorithms are acceptable. The JWK metadata includes alg and use, but a verifier should never trust a token header blindly or accept alg: none. Asymmetric algorithms such as RS256, PS256, ES256, and EdDSA let many services verify a token without sharing a signing secret, which is the reason JWKS fits distributed systems. The security difference is not just cryptographic strength. It is also about preventing confused-deputy behaviour, where a validly signed token is treated as acceptable in the wrong context.

Practical implication: configure explicit algorithm allowlists and reject any token that relies on an unexpected or unsupported signing method.

Threat narrative

Attacker objective: The attacker wants a service to accept an untrusted or mis-scoped token as legitimate so they can gain unauthorized access without knowing the private signing key.

1. Entry occurs when a service accepts a JWT that has been signed elsewhere but has not been fully validated for issuer, audience, expiration, or algorithm restrictions.
2. Credential abuse follows when a forged or misapplied token is trusted because the verifier checks the signature but not the surrounding claims or key selection logic.
3. Impact is unauthorized access to APIs or sessions that should have rejected the token, turning a verification weakness into an authentication failure.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JWKS is a verification control, not a trust decision. Publishing public keys lets resource servers verify signatures locally, but the trust decision still depends on issuer, audience, expiry, and algorithm policy. That distinction matters because many programmes treat cryptographic validity as if it were authorization validity. Practitioners should treat JWKS as one layer in the token trust stack, not the stack itself.

Cache behaviour is part of identity governance. JWKS caching is often discussed as a performance choice, but it is also a governance control because it determines how quickly rotation, compromise, and key replacement take effect. A verifier that never refreshes on kid miss can break valid authentication after rotation, while a verifier that refreshes too freely can be abused into repeated outbound lookups. The practical issue is controlled freshness, not static configuration.

Algorithm allowlisting closes a common verification blind spot. The presence of a JWK does not mean every signing method should be accepted, and alg metadata should not be treated as authoritative by itself. Identity teams need to define which algorithms are permitted for each issuer and service boundary. That is especially important in distributed environments where one weak verification rule can compromise many downstream services.

Key rotation only works when old keys remain trusted long enough to cover live tokens. JWKS solves this by allowing overlap, which is exactly why rotation is operationally safer than ad hoc key replacement. The governance lesson is that key lifecycle management and token lifetime policy are inseparable. If the rotation window and token validity window are not designed together, one will eventually undermine the other.

Public-key publishing exposes the identity boundary between issuers and verifiers. JWKS makes that boundary explicit, which is useful because it forces teams to decide who owns signing, who owns validation, and who owns response to key compromise. That clarity aligns with NIST CSF access permissions and OWASP-NHI principles around secret exposure and overtrusted non-human identities. Practitioners should use it to harden the verification boundary, not to bypass governance.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Read next: Cryptographic Key Management Guide

What this signals

JWKS verification only works when the verification boundary is explicit. Identity teams should treat public key lookup, claim validation, and algorithm policy as separate controls, because collapsing them into one step creates a false sense of trust. The operational question is no longer whether a token can be verified, but whether it should be accepted for this service and this session.

Token trust debt: when teams defer cache discipline or algorithm pinning, they accumulate a gap between cryptographic correctness and governance correctness. That gap shows up later as brittle rotation, confusing outages, or acceptance of tokens that should have failed validation. The fix is to govern the entire verification path, not just the key material.

For practitioners

• Validate the full token trust chain Check issuer, audience, expiration, and not-before claims in addition to the signature before accepting any JWT in production paths.
• Pin accepted signing algorithms Define an explicit allowlist for each service boundary and reject tokens that use none, unexpected algorithms, or unapproved key types.
• Treat JWKS refresh as a controlled control Cache JWKS responses according to cache headers, refresh on kid miss, and rate-limit refetches so verification remains stable during rotation.
• Design rotation around token lifetime Keep overlapping keys available until the oldest live tokens signed by the outgoing key have expired, then retire the old key.
• Separate signature validity from authorization Require downstream services to make an explicit authorization decision after verification instead of assuming a valid signature implies permitted use.

Key takeaways

• JWKS makes distributed JWT verification practical, but it does not replace issuer, audience, expiry, and algorithm controls.
• Overlapping keys are what make rotation safe, while stale cache behaviour and loose refresh rules make it unreliable.
• The strongest control point is the verifier, where claim validation and algorithm allowlists decide whether a signed token should be trusted.

Key terms

• JSON Web Key Set: A JWKS is a JSON document that publishes one or more public keys for verifying JWT signatures. It lets relying services fetch the correct verification key by key ID, which supports distributed authentication and key rotation without sharing private signing material.
• Json Web Key Set: A published set of public keys used to verify signed tokens and support automated key rotation. JWKS lets clients discover the current verification keys from a central endpoint instead of distributing PEM files manually, which reduces drift in distributed authentication systems.
• Key ID: Key ID, or kid, is the identifier that tells a verifier which key in a JWKS should be used for a given JWT. It reduces ambiguity during rotation and multi-key deployments, but it is only reliable when the verifier also enforces issuer and algorithm rules.
• Claim Validation: Claim validation is the process of checking whether token fields such as issuer, audience, subject, and expiry match the expected security context. It is the control that prevents a validly signed token from being accepted in the wrong place, for the wrong system, or after its intended lifetime.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.