无kid字段的JWT验证：如何从JWK中选择密钥？

Great question—this is a super common edge case that trips up a lot of developers working with OAuth/OIDC and JWTs. Let’s break down the proper approach, rooted in specs and real-world implementation:

What the Specs Say #

First, let’s anchor this to the relevant RFCs (RFC 7519 for JWT, RFC 7517 for JWKs):

• The kid (Key ID) header parameter is optional for JWTs, but its whole purpose is to cut down on guesswork when multiple signing keys are available.
• When no kid is present, you can’t rely on direct key ID matching—so you need to use other metadata from the JWT header and your JWK Set to narrow down valid candidates.

Step-by-Step Validation Workflow #

Here’s the practical, spec-aligned process to follow:

1. Grab the alg field from the JWT header
   This tells you the signing algorithm used (e.g., RS256, ES256, HS256). Each algorithm maps to a specific key type (kty in JWK terms):
   • RSA-based algorithms (RS256/RS384/RS512) require keys with kty: RSA
   • Elliptic Curve algorithms (ES256/ES384/ES512) require kty: EC
   • HMAC algorithms (HS256/HS384/HS512) require kty: oct (symmetric octet sequences)
2. Filter your JWK Set to match the required key type
   From your pool of JWKs, keep only those where the kty value matches what’s required for the JWT’s alg. This eliminates keys that can’t possibly validate the signature (e.g., an EC key will never work for an RS256-signed token).
3. Test each filtered key against the JWT signature
   Iterate through the remaining keys and attempt to verify the JWT’s signature with each one. Stop at the first key that successfully validates the signature—this is your match.

Key Best Practices & Gotchas #

• Never skip validation, even for a single candidate: If filtering leaves you with one key, always run the signature check—don’t assume it’s correct just because it’s the only one left.
• Push for kid in issued tokens: This edge case is avoidable! Including kid in JWT headers is always preferable—it cuts down validation time (no need to iterate through keys) and removes ambiguity.
• Libraries handle this for you: Most production JWT libraries (like Java’s jjwt, Node.js’s jsonwebtoken, or .NET’s System.IdentityModel.Tokens.Jwt) have built-in logic for this scenario. Just pass the full JWK Set to the library’s validation method, and it’ll handle filtering and iteration automatically.
• Multiple valid keys = red flag: If more than one key successfully validates the token, that’s a problem—it could mean duplicate keys in your JWK Set or a compromised signing key. Treat this as an error and investigate immediately.

内容的提问来源于stack exchange，提问作者David Alsh