The client_assertion token has an expiration too far into the future

[alx]

Hello,

I have a Spring Boot application which uses the Okta SDK. I created an Okta Service Application which uses a public/private key to authenticate my Spring application.
The problem: I stopped my Spring application for a longer period of time (a couple of weeks), at startup I get the error:
Caused by: com.okta.sdk.impl.oauth2.OAuth2HttpException: invalid_client - The client_assertion token has an expiration too far into the future. Caused by: com.okta.sdk.resource.ResourceException: HTTP 401, Okta null (null)
This problem seems to be self fixing, sometimes it takes hours until I am able to startup my application, other times it starts after a second startup attempt, lot’s of times it starts without any error.

From the Okta System Log, the reason for the fail is: client_assertion_expires_too_far_in_future.
I couldn’t find anything related to this problem in the documentation, so maybe someone knows what the problem is and can give some solutions?

Thank you.

[erik]

Hi,
I assume you are using our SDK to create the JWT token used in the client assertion? If so are you specifying either of these claims (‘exp’, ‘iat’) when creating the JWT? If so can you try creating the JWT without specifying these values.

[alx]

Hello,

Maybe I am misunderstanding, but assuming I made a mistake, let me explain to what I am referring: I build a Service Application in Okta which uses a private/public key to achieve authentication of my Spring Application. I followed this guide , according to the guide the Okta SDK is doing the creation and signing of the JWT so actually I don’t have to do anything except configuring the Okta Client, which I did like so:

import com.okta.sdk.client.Clients;
this.oktaSdkClient = Clients.builder()
.setConnectionTimeout(…)
.setOrgUrl(…)
.setAuthorizationMode(…)
.setClientId(…)
.setScopes(…)
.setPrivateKey(…)
.setRetryMaxAttempts(…)
.build();

So am I missing something from the Clients configuration?

[erik]

Hi,
It looks the SDK creates the assertion with a 1 hour expiry period and possibly the backend wont allow any tokens with an expiry longer than 1 hour. If I set my system clock 1 minute ahead I am able to reproduce the issue. I am checking if this value can be configured, but do you know how your systems time is set? I assume with a time server. If there is too much drift in the future this issue will occur.

[alx]

Hello,

Cool! Nice catch. I confirm - managed to reproduce this as well on my side.
I use the SDK in my local playground which is running a basic Windows 10 installation. The time server is the default time.windows.com and it was last synced on the 26th of Dec and of course that because of this my application did not start. I did a force sync and the application started successfully.
I will check further to see why sometimes my time is not synchronized automatically by Windows.

But yeah, thanks a lot for this it was really grinding my gears

Cheers