"JWKS Key Not Found" / kid Mismatch, Explained

This means the token's header points at a key that isn't (or is no longer) in the identity provider's published key set — a different failure mode from a bad signature or an expired token.

What triggers it

A JWT signed with RS256/ES256 etc. carries a kid (key ID) in its header identifying which public key to verify it against:

{
  "alg": "RS256",
  "kid": "2024-03-key-1",
  "typ": "JWT"
}

The verifier fetches the identity provider's JWKS (usually at /.well-known/jwks.json) and looks for an entry with a matching kid. If none exists, verification fails before the signature is even checked — there's no key to check it against.

Why this usually means key rotation

Identity providers rotate signing keys periodically for security, publishing a new key and eventually retiring the old one from the JWKS. If a token was signed with a key that's since been retired — or if your app cached an old JWKS and hasn't refreshed it — you'll see exactly this error. It's rarely a sign of a forged token; it's almost always a caching or timing issue.

How to debug it

1. Decode the token's header (without verifying) in the JWT Decoder to read its kid.
2. Fetch the current JWKS from the provider's /.well-known/jwks.json endpoint and paste it into the JWKS Inspector to list every kid currently published.
3. If the token's kid isn't in that list, the token was signed with a retired key — it needs to be re-issued, not "fixed."
4. If your application caches the JWKS, make sure it refreshes periodically (most JWT libraries support this) rather than fetching it once at startup.

Handle rotation safely

When an unknown kid appears, refresh the JWKS once and retry verification, but rate-limit that path. An attacker can send random key IDs to force repeated outbound requests. Respect cache headers while also allowing a controlled refresh during rotation, and keep previously valid keys for the issuer's documented overlap window when policy permits.

Confirm the issuer before selecting a JWKS endpoint. Fetching a key set based on an untrusted token field can create an SSRF or key-confusion vulnerability. Pin trusted issuers to configured HTTPS endpoints, validate TLS, restrict algorithms, and reject ambiguous duplicate key IDs. Never treat “a key with this ID exists somewhere” as proof that it is trusted for the token.

Unknown kid failure matrix

• Wrong issuer: the token and configured JWKS belong to different identity providers; reject it and fix issuer routing.
• Stale cache: the live JWKS contains the kid but the application cache does not; refresh once with rate limiting.
• Retired key: neither the live nor cached JWKS contains the kid; request a new token instead of trusting another key.
• Duplicate key ID: more than one trusted candidate shares the kid; reject the ambiguous set and fix the issuer configuration.

Verification notes and primary sources

Reviewed by Semih Buğra Sezer on 14 August 2026. The meaning of kid follows RFC 7517 section 4.5. Operational refresh and retention behavior remains issuer-specific, so verify the provider's rotation and cache documentation before changing production policy.

Frequently Asked Questions

Related Tools and Guides