Cache invalidation / TTL for createRemoteJWKSet

[ghdoergeloh]

Hi, thanks for this great package.

It is really easier to use with jwks than jsonwebtoken.

But there is one feature missing - or I can't see it. I would like to invalidate the cached jwks automatically after a specified time.

If a key is compromised it should be invalidated on the auth server so a jwk would be deleted from the list. That means the cache needs to be invalidated after a specified time and the jwks must be requested again. Ist there such a feature?

[panva]

If a key is compromised it should be invalidated on the auth server so a jwk would be deleted from the list.

In that case the Authorization Server will publish its new JWKS and starts using it, so a new kid will be used in the tokens and the cache will be automatically dropped and JWKS re-fetched.

If you want manual invalidation control though, you just need to invoke createRemoteJWKSet again and pass the result of that to your respective verify function.

[panva]

But that's the equivalent of

let JWKS = jose.createRemoteJWKSet(...)

async function verify(...) {
  return jose.jwtVerify(token, JWKS, ...)
}

setInterval(() => {
  JWKS = jose.createRemoteJWKSet(...)
}, 5 * 60 * 1000)

[panva]

Given, the timers for cooldown are reset but I don't see a problem with that.

[ghdoergeloh]

in a context like aws lambda setInterval is not the best approach but it could be done with an extra function:

let JWKS: GetKeyFunction<JWSHeaderParameters, FlattenedJWSInput> | undefined;
let chacheUpdated = 0;
const chacheTTL = 5 * 60 * 1000;

function getJWKS(): GetKeyFunction<JWSHeaderParameters, FlattenedJWSInput> {
 if (!JWKS || Date.now() > chacheUpdated + chacheTTL) {
   JWKS = jose.createRemoteJWKSet(new URL(OIDC_JWKS));
   chacheUpdated = Date.now();
 }
 return JWKS;
}
async function verify(token: string) {
 return jose.jwtVerify(token, getJWKS());
}

But it is still not a really nice workaround. If the cache of the createRemoteJWKSet-result was just updated before the end of the 5 minutes because of an unknown kid there is no need to update the cache within the next 5 minutes. but this approach would update it anyway.

However. I know, this is very theoretical and maybe not relevant for most of the users, I just thought we could add a simple property to give users who need it (for example for compliance requirements) the possibility to use it.

[panva]

I will think about it, please open a PR (from a new branch in your fork. That way, should I decide to pull the trigger, you will get the contribution attributed even if I change the implementation in the PR.

[ghdoergeloh]

here it is: #395