Add request throttling support

[bdemers]

Limit the number of outbound requests to the /key endpoint.

[rafikiassumani]

How long keys get cached? Can you provide a setter to override the default?

[bdemers]

Currently public keys are cached until a new keyid is requested (and not found in the cache) at that point the key store is updated to reflect the current set of keys.

The goal of this issue is to add a minimum time between those requests.

[blackjackyau]

in the case of current key "kid A" got cracked and we have performed the key rotation from Okta. How do we invalidate the "kid A" from the cache ?

[bdemers]

@blackjackyau the easiest way is to create a new instance of the Verifier. This would be application-specific code. We generally recommend reducing the amount of time a JWT is valid to help mitigate risk. For example, if your tokens were only valid for 5 minutes, your application would only be at risk for 5 minutes.

[blackjackyau]

@bdemers i see, the public key will be cached until the new kid is located and hence a shorter timer of access token will help. However, this solution might not be ideal in the micro-service world where the service flow will be depending on user action. That might leave some applications be prone to attack

[bdemers]

How so? You could clear the cache (by creating a new instance) and minimize the duration of the token (this part is just general advice)

[blackjackyau]

@bdemers i mean, this should be configurable from the verification. like how auth0 does it ? https://github.com/auth0/jwks-rsa-java

JwkProvider provider = new JwkProviderBuilder("https://samples.auth0.com/")
    .cached(10, 24, TimeUnit.HOURS)
    .rateLimited(10, 1, TimeUnit.MINUTES)
    .build();
Jwk jwk = provider.get("{kid of the signing key}"); //throws Exception when not found or can't get one

[bdemers]

We do have plans to improve the caching (and allow for pluggable caching as we have in our management SDK)

However, the goal of this library is not a general-purpose JWT library (I'd recommend JJWT for that), so how the cache is used would still be tailored to Okta (I'm not sure if that is your intent or not).

You would want to invalidate the cache somehow on demand in the case of a leaked private key (and not wait until the cache timeout).

Thanks for the feedback!

[blackjackyau]

@bdemers thanks for that. Yes in my case, a force cache invalidation will be the way but it is also good if i am able to define the worst risk time