JWKS and kid explained: how verifiers find the right public key

How this is calculated

OpenID Connect providers list their JWKS URL as jwks_uri in /.well-known/openid-configuration, so a verifier only needs the issuer's address. The kid is just a label. It lets the issuer rotate keys without breaking anything: it publishes a new key next to the old one, starts signing with it, and removes the old key after the last tokens signed with it have expired. Verifiers should cache the JWKS and refresh it when they see a kid they don't know, with a rate limit so random kids can't make them hammer the endpoint. A key in the set may carry alg, use and key_ops members. alg ties the key to one algorithm, use "sig" marks it for signatures, and key_ops can say "verify". A careful verifier respects all three. The token header can also carry jku (a JWKS URL), x5u (a certificate URL), jwk (a whole key) or x5c (a certificate chain). Those are dangerous to trust, because an attacker can point them at a key they control. The JWT Decoder accepts a pasted PEM key, a single JWK or a whole JWKS, picks the key by kid, refuses private keys, and never fetches or trusts a key from the token itself.

Verdict

Configure the issuer and its JWKS URL in your service, not in the token. Match by kid, check kty and alg, cache with a refresh on unknown kids, and keep the old key published for at least one token lifetime after rotation.