VerifyJWT JWKS Uri Caching

I'm planning to use the VerifyJWT policy and use the uri for caching of the JWKS. I haven't seen how caching is implemented except for the fact that the cache retains the JWKS for 300 seconds.

How does it behave if it encounters an unknown kid in the JWT header? Would it immediately fetch the JWKS and refresh the cache?

Solved Solved
0 2 1,106
1 ACCEPTED SOLUTION

Nope, the cache management is fairly simple. It does not cache based on kid. It caches the entire JWKS using the JWKS URI as the cache key.

The assumptions behind the JWKS cache is

  • JWKS content is small
  • keys change slowly
  • new keys get added to the JWKS before there are JWT signed with those keys
  • old keys get removed only AFTER the expiration of the last JWT signed with that key

If you have the case in which you are introducing a new key, signing JWT with that new key, and updating the JWKS endpoint all within 5 minutes, then the cache assumptions won't hold.

To avoid this

  1. add new keys to the JWKS before you begin using the keys
  2. remove old keys from your JWKS lazily

There is an outstanding feature request to allow the caching to respect the HTTP caching headers. That seems reasonable. The practical effect of that will most likely be to have a LONGER TTL for the cached JWKS.

View solution in original post

2 REPLIES 2

Nope, the cache management is fairly simple. It does not cache based on kid. It caches the entire JWKS using the JWKS URI as the cache key.

The assumptions behind the JWKS cache is

  • JWKS content is small
  • keys change slowly
  • new keys get added to the JWKS before there are JWT signed with those keys
  • old keys get removed only AFTER the expiration of the last JWT signed with that key

If you have the case in which you are introducing a new key, signing JWT with that new key, and updating the JWKS endpoint all within 5 minutes, then the cache assumptions won't hold.

To avoid this

  1. add new keys to the JWKS before you begin using the keys
  2. remove old keys from your JWKS lazily

There is an outstanding feature request to allow the caching to respect the HTTP caching headers. That seems reasonable. The practical effect of that will most likely be to have a LONGER TTL for the cached JWKS.

Thank you @dchiesa1 !