Add capability for using stale cache while JWKS endpoint is down

[flaviostutz]

Sometimes the JWKS endpoint may be down. In these cases, it would be useful if jose could still use a stale version of the cached keys even after cacheMaxAge has passed to avoid outages in a service.

[KeithRichardsonKR]

I think this is a very important feature. It's not good for a network issue or outage on the JWKS endpoint to take down the JWT-secured API, so it leaves us with two choices:

1. Set cacheMaxAge to a very log time/infinite so that the cache never expires (a new kid will refresh the cache)
2. Keep a cacheMaxAge, but potentially have an outage if JWKS is ever down

Would it be reasonable to update getKey to catch errors on this.Reload() and continue if there was an error in reloading the cache?
Code link as of time of post:

jose/src/jwks/remote.ts

Line 117 in f009cc1

await this.reload()

Maybe there can be config of whether to allow using a stale cache? Alternatively, there could be a staleMaxAge as well, so you could have your config set like this:

cacheMaxAge: 1 day
staleMaxAge: 2 days

So it will try to refresh after 1 day, but if there's errors on reload() it will use the stale cache up to another day, after which it will start returning errors like it currently does. The staleMaxAge could default to be the same as cacheMaxAge if not set.

Would you be open to a pull request for this feature?

[KeithRichardsonKR]

@panva, my proposal would be to create a cacheStaleMaxAge config setting. If an error occurs during this.reload() and cacheStaleMaxAge milliseconds have not elapsed since the cache was last loaded, it would use the existing cached keys. If there was an error and cacheStaleMaxAge milliseconds have elapsed, it would return the error as normal.

Would you be willing to consider a pull request with this feature if I submitted it? Thanks!

[panva]

I don't quite get the point. You already control accepting "stale" with the existing cache option.

If a rotation is detected and the jwks endpoint is down the token which needs keys fetched still wont validate while others will be fine.