Solved: Verify JWT caching

khaled10x

Hi,

Is there a way to change the default caching value for the VerifyJWT policy which is 300 seconds as mentioned here: https://cloud.google.com/apigee/docs/api-platform/reference/policies/verify-jwt-policy#publickeyjwks

And what will happen if the IAM provider change the configuration will it return invalid responses for the whole 5 minutes?

dchiesa1

Is there a way to change the default caching value for the VerifyJWT policy which is 300 seconds as mentioned here: https://cloud.google.com/apigee/docs/api-platform/reference/policies/verify-jwt-policy#publickeyjwks

Not currently, not directly. You COULD lengthen the caching period, if you put the JWKS endpoint behind an Apigee proxy, and set the caching on the Apigee proxy (via ResponseCache policy) to be ... something longer than 5 minutes. But I think that would be ... probably not super useful.

And what will happen if the IAM provider change the configuration will it return invalid responses for the whole 5 minutes?

No, it shouldn't. When IAM providers rotate keys they must allow an overlap period. Usually this is 24 hours or more. The way i works: they introduce a new key into the JWKS, before the key us ever used to sign anything. Then the IAM provider waits some amount of time, THEN begins using the new key to sign things. By that point, the readers of the JWKS are highly likely to have refreshed their caches.

There's an item in the backlog to make Apigee be smarter about caching the JWKS according to the HTTP cache headers. But that change hasn't been merged yet. the lack of this change isn't causing errors or problems, AFAIK. It's really just an efficiency thing.

View solution in original post

dchiesa1

Is there a way to change the default caching value for the VerifyJWT policy which is 300 seconds as mentioned here: https://cloud.google.com/apigee/docs/api-platform/reference/policies/verify-jwt-policy#publickeyjwks

Not currently, not directly. You COULD lengthen the caching period, if you put the JWKS endpoint behind an Apigee proxy, and set the caching on the Apigee proxy (via ResponseCache policy) to be ... something longer than 5 minutes. But I think that would be ... probably not super useful.

And what will happen if the IAM provider change the configuration will it return invalid responses for the whole 5 minutes?

No, it shouldn't. When IAM providers rotate keys they must allow an overlap period. Usually this is 24 hours or more. The way i works: they introduce a new key into the JWKS, before the key us ever used to sign anything. Then the IAM provider waits some amount of time, THEN begins using the new key to sign things. By that point, the readers of the JWKS are highly likely to have refreshed their caches.

There's an item in the backlog to make Apigee be smarter about caching the JWKS according to the HTTP cache headers. But that change hasn't been merged yet. the lack of this change isn't causing errors or problems, AFAIK. It's really just an efficiency thing.

khaled10x

Thanks @dchiesa1

But what will be the policy behavior if the IAM providers rotate keys without an overlap period, Will the policy make a new request to the new keys after the first failure request, or will it wait for the cache to refresh?

Best regards.

dchiesa1

No - if the Identity provider rotates incorrectly, the policy will not try to adapt to that situation.

If the identity provider:

- removes a key from the JWKS, while still signing JWTs with that key

- uses a key to sign a JWT before listing it in the JWKS,

..., the VerifyJWT policy will not re-attempt to download keys.