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! Go to 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
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
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.
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
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
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 !
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 |