[maikdijkstra]

Summary

 Keypair.jwt_decode
   jwks: jwk_loader_cached
     cached_jwks(force: unknown kid)
-      Rails.cache.fetch('keypairs/Keypair/jwks')               # never expires
+      Rails.cache.fetch('keypairs/Keypair/jwks/v2')            # new key: old entries never expired
+        expires_in = min(5 minutes, first keypair expires_at - now)

Without an expiry, the cached JWK Set was only refreshed when a token had an unknown kid. Because the next keypair is published ahead of time, rotation rarely triggered that, so keypairs past their expires_at, or deleted after a compromise, kept validating signatures for as long as the cache store kept the entry.

The first expiry comes from the keypairs that keyset already loads (now valid_keypairs), so this adds no extra query.

Found during a JWT audit of drieam-lti, which will require this release instead of patching Keypair itself.

Evidence

• Before: the new .cached_jwks specs fail, e.g.

  cache keyset while keypair is valid
  travel 11 minutes (keypair expired after 10)
  jwt_decode(token signed by expired keypair) → payload returned
  

  After: 105 examples, 0 failures → raises JWT::DecodeError. RuboCop is clean.

Merge Danger

Door: two-way

Code-only. Reverting falls back to the old cache key.

Blast Radius: signature validation

• Database load: apps rebuild the cached JWK Set at least every 5 minutes. That's one query plus, at most, creating the next keypair, which keyset already does.