Time taken to validate JWT token

[vksonpdl]

Hi, I’m using below java library to validate the JWT token. but the ‘decode’ method is taking almost a second. do we know if there is any performance improvement ?

Validate Access Tokens | Okta Developer

[erik]

Hello,

If I run,

        long start = System.currentTimeMillis();
        Jwt jwt = jwtVerifier.decode("eyJraW...");
        long finish = System.currentTimeMillis();
        System.out.println("Time: " + (finish - start));
        start = System.currentTimeMillis();
        jwt = jwtVerifier.decode("eyJraW...");
        finish = System.currentTimeMillis();
        System.out.println("Time: " + (finish - start));

where the first access token is a different value then the second I get,

Time: 885
Time: 1

The first call will do some initialization, download the /keys from the authorization server. Once this is done the following calls should be fast.

[vksonpdl]

Hi @erik
Please find the below code i’m using for token decode/validation

Please find the logs below. for first call, the decode method took 2.6 seconds and the for the subsequent calls decode method is still taking ~1.5 seconds

[erik]

Every time a token is validated it looks like validateHeader() is called. Which creates a new instance of AccessTokenVerifier, so I believe the /keys endpoint will be called each time and the other initialization.

Can you test where you use a persistent instance (class member, static, bean, etc) of AccessTokenVerifier? Don’t create it each time.

If I create an instance of AccessTokenVerifier and verify 3 tokens, then create a new instance and verify 3 more tokens I see,

Time: 953
Time: 1
Time: 1
Time: 431
Time: 1
Time: 1

So the first decode() of a newly created instance is causing overhead.
This is due to the first time it validates a token it needs to check if it has the kid for the token cached which it won’t, so it downloads the key.
I assume this time is cut in half the second time an instance is created perhaps due to keep alive for the network connection to make the /keys call. But I would need to trace/debug to know for sure.

Either way using a persistent instance will improve performance substantially.

[vksonpdl]

Thanks @erik ,

your solution was really helpful, now within 2 milli-seconds the token validation is happening.

do you know the key caching expiry time, how long the key will be cached and when it will be invalidated and get new key ?

also, I’m creating AccessTokenVerifier as a bean but the application is running in multiple pods, for example if the service is running in 10 pods, first 10 call to the api will take more than 500 milli-seconds (each pod service has to cache the key)

is there any way we can do the key caching on the application start-up, rather than waiting for the first request?