Remote verifier reloads JWKs when encountering unknown kid

[bittrance]

The current implementation of RemoteJwksVerifier relies on a fixed duration to cache the JwkSet it requested. I want to set cache_duration high so as not to have my availability constrained by the IDP. However, when the IDP rotates one of its signing keys, JWTs with unknown kids will start showing up which will incorrectly fail verification. I think periodic JWK rotation is an IDP good practice. Partly, this reduces the vulnerability window should the keys be exfiltrated, but it also ensures all consumers can deal with key rotation.

The solution to this is to reload the JwkSet when encountering an unknown kid. This way, the first unknown key will reload the set and try verification again. So long as the IDP does not rotate out a JWK which still has valid JWTs, key rotation will be transparent to clients. As a side-effect, if all JWKs are rotated at once (e.g. suspected breach), the first new JWT to show up will cause the RemoteJwksVerifier to drop its old keys, thus reducing the vulnerability window. However, this would enable using the verifier to amplify DOS attacks on the IDP. To mitigate this, we introduce a cooldown timer that limits how often we will request JWKs.

This solution is borrowed from https://github.com/panva/jose/blob/4261556a123ae2dc5c5f238465eff7eb9404b293/src/jwks/remote.ts#L121 .

[blckngm]

It's very reasonable to reload when encountering an unknown kid (with a cooldown). However I wonder whether we can have a better API (e.g. builder) for configuring RemoteJwksVerifier to do this while maintaining compatibility for users who don't opt-in. Let me try this.

[bittrance]

Agreed. I cringed a bit at adding the fourth argument to the constructor and also thought that a builder might be an improvement.