Use without querying /default/v1/keys ?

[okta]

Use without querying /default/v1/keys ?

[bdemers]

@navinpai Yup, that is the issue, reuse that instance to reuse the same cache!

[bdemers]

Hi @navinpai !

Thanks for checkout out this project.
The keys are cached so the only time a remote request is made is if the key is not cached yet. Depending on key rotation this might only be a couple times per year.

Is there a specific condition you are testing?

[navinpai]

I'm unsure if that is the case, since it looks like for every token decode we are doing, the external URL (/default/v1/keys) is hit. It's a fairly simply REST API for token validation, and is similar to the code below:

public String verifyToken(String accessToken) {
    AccessTokenVerifier jwtVerifier = JwtVerifiers.accessTokenVerifierBuilder()
                                                      .setIssuer(ISSUER_URL)
                                                      .setAudience(AUDIENCE)
                                                      .setConnectionTimeout(Duration.ofSeconds(1))
                                                      .setReadTimeout(Duration.ofSeconds(1))
                                                      .build();
    try {
        // This takes 1.5 seconds or more since it makes a call to Okta everytime
        Jwt jwt = jwtVerifier.decode(accessToken);
        return (String) jwt.getClaims().get("uid"); 
    } catch (JwtVerificationException e) {
          logger.error("local introspect error", e);
          return ERROR;
    }

}

I'm unsure why the caching isn't working but every call to the API ends up taking a second or 2 since it makes an external URL call.

Any help with this would be appreciated.

Edit: Also, if it matters, we're running Java 1.8 with v0.4.0 of okta-jwt-verifier-impl and okta-jwt-verifier

[bdemers]

I’ll take a look!

[donlingliang]

I’ll take a look!

@bdemers Could you also take a look if this keyMap caching works for multiple threads? Thanks.

[bdemers]

reading from multiple threads shouldn't be an issue, but the rare updates may cause additional requests (the current cache mechanism is a bit naive). Key rotation happens ~4 times a year.

That said the plan is to grab the caching logic from our SDK (and then you could drop in any type of cache you wanted to)

[donlingliang]

reading from multiple threads shouldn't be an issue, but the rare updates may cause additional requests (the current cache mechanism is a bit naive). Key rotation happens ~4 times a year.

That said the plan is to grab the caching logic from our SDK (and then you could drop in any type of cache you wanted to)

okay, so back to the original question that @navinpai posted, did you find out what causes the rare updates and the solution(manually doing the key rotation own self may not be a good choice if you already had a better solution)?

[asherzog]

@bdemers is this issue still being looked at? We have started running into rate limit warnings and violations from Okta for the /keys endpoint because the keys are not caching and requests are being made for every token validation.

[bdemers]

@asherzog and @navinpai can you confirm you are using the same instance of AccessTokenVerifier/IdTokenVerifier each time you are validating a token?

[navinpai]

Is that the issue? I've posted the code I'm testing with above: #49 (comment)

I create a new AccessTokenVerifier for every call to the verifyToken method. Should I unstead just use AccessTokenVerifier as a class level instance?