When JWK changes, clients may hold valid (and unexpired) JWTs signed with the previous signing key and Istio will block the request. In order to avoid blocking service requests while the clients are busy fetching new access tokens, can Istio allow validating tokens signed with the previous key for an extra amount of time for example grace period of 5 minutes? If yes, how to do it? If no, is there any other way to achieve it?
How exactly is the JWK changing in this scenario?
Is the Service issuing the JWT changing the content of its JWK by adding a new signing key? In this case, my understanding is most such services take care to not purge their previous signing keys for considerably longer than 5 minutes.
The other scenario (I can think of) is if we manually change the jwkURI in our request Authentication resource. However, given that
(a) this is a manual intervention,
(b) tokens are expected to last for a short time which makes it fairly standard for clients to request new tokens and
©This is a security issue where interruption of service is tolerable as opposed to allowing malicious actors with slightly older tokens access to the service
Could you elaborate further why you think previous tokens should be allowed?
Thanks for the reply! JWK is changed by the access management system issuing the JWT. I will check the configs of the system whether they will take care of not purging it or not.
In our case, previous tokens should be allowed to minimise downtime of the service.
As Shankar mentioned, this is not something Istiod should work around against. Your JWK management side should ensure not rotate to new keys unless all JWT signed by old keys are expired or okay to ignore them (e.g. trigger re-authentication flow is acceptable).
1 Like