Apigee JWT token verification using JWKS

[abhijithsh]

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.

@idiche @dchiesa1 @API-Evangelist 

[dchiesa1]

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

• your observation that there is not a significant difference in timing between one request and another, even when you think a JWKS retrieval should occur, is probably irrelevant. Caching can occur in multiple layers. Also measuring the performance of a distributed system using a sample size of 1 or 2 transactions is not reliable.  You need thousands, millions of requests, which I am assuming you did not do, in order to assess performance at scale. 
• You should not care about the caching, it should just work. 

[API-Evangelist]

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)..

https://cloud.google.com/apigee/docs/api-platform/reference/policies/verify-jws-policy#publickeyjwks

Caching plays critical role when you are planning to do rotation or revocation use cases(certain use cases in open banking usually experiences) but good to practice regular refresh of keys/revoke to mitigate the risk of security vulnerabilities if the keys are compromised....try to test such scenario's & share your experiences & may be opportunity to enhance the policies (like exposing a property for cache limits as apposed to standard 5 min)

 (you may still observe as the policy it should be jose implementaiton (or similar) if you run a good load tests)

Good luck.

[dchiesa1]

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.