Pattern for invalidating cached remote JWKS

[joshkadis]

Hello! I've read through #394 and would like to make sure I'm understanding the pattern correctly for invalidating cached remote keys. In my case, the authorization service does not rotate keys regularly. A new key set is only published if the keys are compromised.

let JWKS = jose.createRemoteJWKSet(MY_URL, { cacheMaxAge: MY_TTL });

// In reality I'd check if the cache has expired on its own
// and do some additional error handling, etc.
async function verify(token) {
  let verifiedToken;
  try {
    verifiedToken = jose.jwtVerify(token, JWKS)
  } catch (err) {
    // will throw ERR_JWKS_NO_MATCHING_KEY if new keys have been published
    if (err.code === 'ERR_JWKS_NO_MATCHING_KEY') {
      // Resets the cached JWKS
      JWKS = jose.createRemoteJWKSet(MY_URL, { cacheMaxAge: MY_TTL });
      verifiedToken = await jose.jwtVerify(token, JWKS)
     }
  }
  return verifiedToken
}

Thanks for the great library!

[panva]

This only opens you up to someone being able to force your process to always reload. You don't need anything but the verify and remotejwks "instance".

[joshkadis]

Thanks, that makes perfect sense about the reloading. And to handle those rare occasions when new keys are published, just wait for the remoteJWKS instance to refresh its cache? I'm not opposed to that

[panva]

When new keys are published they will usually be accompanied by a new kid which is then reflected in newly issued tokens. The first time a valid kid is encountered the remoteJWKS instance will do a reload automatically. You won't even notice this happened as it is seamless. At most you will notice the time to verify a token took longer because there was an HTTP fetch as part of the operation.