I am using Apigee built in policy to verify a JWT using JWKS from Onelogin. Saw the document that the public keys are cached for 3 minutes, then cleared and fetched again.
I was trying find how much time is taken during the first call to the request where the JWKS is fetched and cached. I was not able to find a request which takes longer time, even after calling the same endpoint in equal interval for more than 3 minutes (Time for the JWKS to be re-fetched).
Is the JWKS not fetched during an API call ? Is it fetched and refreshed in a separate mechanism so that none of the request is affected. I could not find any details on this in documentations. Hope someone can explain. Thanks in advance.
ok it sounds like you're just posing a question, but you're not observing a specific problem.
The JWKS is fetched and refreshed independently of the execution of the policy. This is an internal implementation detail, so it's not documented and is not part of the supported interface of Apigee. But currently, there is an independent service that does the retrieval and caching.
Also, there are multiple levels of cache. HTTP resources can cache and return "304 Not modified" in which case the caller will simply retain what it already has. And network systems that intercede between the caller and the JWKS endpoint can also return cached results since 304 responses often include an expiry.
The bottom line is
If you use custom java callout you may observe/control the behavior but with OOB policy if it is documented as 300 sec & may be run a good load test you may observe the behavior (few req may take time & others are cached response internally)..
(you may still observe as the policy it should be jose implementaiton (or similar) if you run a good load tests)
Good luck.
Yes- one way to control the cache/refresh interval of JWKS is to use a ServiceCallout to retrieve the JWKS, and then store it in the Apigee cache. Effectively wrap that ServiceCallout in a LookupCache / PopulateCache policy set.And you get to set the expiry directly, in your proxy. Then in the VerifyJWT policy you can simply refer to the variable that holds the JWKS content. While this will work and will be reliable, it is a lot of effort that you probably don't need, unless you need to circumvent normal JWKS expiry (like explicitly and unilaterally revoke a published key), or take some other extraordinary step.