JWT Verification Timeout Java

How do I extend the timeout allowed to validate a JWT?
I’m using:


Caused by: com.nimbusds.jose.RemoteKeySourceException: Couldn't retrieve remote JWK set: Read timed out
at com.nimbusds.jose.jwk.source.RemoteJWKSet.updateJWKSetFromURL(RemoteJWKSet.java:141)
at com.nimbusds.jose.jwk.source.RemoteJWKSet.get(RemoteJWKSet.java:219)
at com.nimbusds.jose.proc.JWSVerificationKeySelector.selectJWSKeys(JWSVerificationKeySelector.java:129)
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:323)
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:284)
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:275)
at com.okta.jwt.impl.NimbusJwtVerifier.decode(NimbusJwtVerifier.java:74)
... 76 common frames omitted
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at com.nimbusds.jose.util.DefaultResourceRetriever.retrieveResource(DefaultResourceRetriever.java:97)
at com.nimbusds.jose.jwk.source.RemoteJWKSet.updateJWKSetFromURL(RemoteJWKSet.java:139)

I have a feeling that increasing the timeout may not help here.

Do you have any network stats for a GET to:


Also, can you share your configuration for your JWT verifier?

After increasing the Timeout it is working.
But i changed timeout values during the debug mode by modifying its value at runtime.
And once i increase timeout values it is working properly.

My concern is, Is there any way i can increase timeout values through code.

Any update on this…

It’s important to note that

java.net.SocketTimeoutException: Read timed out

means that the network request timed out, not that the JWT expired or the validation process timed out.

The JWT library is trying to request the JWK set (public signing keys) from Okta (updateJWKSetFromURL) and it looks like that network request is failing. This isn’t a configuration issue - it might be something wrong with your network. Is your internet connection intermittent or unreliable?

In the RemoteJWKSet class below is the timing provided which is 250ms which is very less due to which code is throwing Connection Time out error.
* The default HTTP connect timeout for JWK set retrieval, in
* milliseconds. Set to 250 milliseconds.
public static final int DEFAULT_HTTP_CONNECT_TIMEOUT = 250;

 * The default HTTP read timeout for JWK set retrieval, in
 * milliseconds. Set to 250 milliseconds.
public static final int DEFAULT_HTTP_READ_TIMEOUT = 250;

Either its default value should increased so that it will not cause connection timeout problem or there should be some kind of provision to increase this time through code.

And my connection is stable and reliable.

Any update on this…

This is an underlying library that we are using. It isn’t Okta code, I need to check with the team on exposing this via configuration. We are going to open up issues on okta-jwt-verifier-java (overlooked on Okta’s part) and log something there to track.

Yeah I have been having the same issue, its pretty sporadic and has been happing to a few different people in different parts of the country for us. Sometimes it works after I ping it numerous times.

My post:

I’ve logged this issue here:

Watch that repo and issue for resolution. We should be able to prioritize this for the next sprint (starting 2018-02-02).

Thanks a lot tom…