Best Practices for handing customers with incorrect clocks

We have customers who tend to have their system clocks inaccurately set on their personal computer. This causes a lot of these errors to occur:
The JWT was issued in the future
The JWT expired and is no longer valid

Are there any best practices to avoid this from being an issue? Is this something commonly done - I personally haven’t experience this with any websites I have ever logged into, so just wondering if this is something that Okta enforces?

@jchabot86 Hi, If it is a clock-drift issue, you may refer the doc here and see if expireEarlySeconds can help.
“Renewing tokens slightly early helps ensure a stable user experience. By default, the expired event will fire 30 seconds before actual expiration time. If autoRenew is set to true, tokens will be renewed within 30 seconds of expiration. You can customize this value by setting the expireEarlySeconds option. The value should be large enough to account for network latency and clock drift between the client and Okta’s servers.”
For calculate clock skew, adding a workaround discussed here for clock issue, y

Thanks! I will dig into that!
Can someone give me a rundown of the checks that Okta does against the okta clock versus the user’s system clock? I understand there’s configurations such as maxClockSkew and expireEarlySeconds that I can use, but want to understand a bit more about the need for this in the first place. It will help in our explanations to our customers as to “why” its important to have their clocks accurate!

@Lijia Sorry for the delayed follow up - I’m still a little confused as to what the “best practice” would be here.
How does “expireEarlySeconds” help here? We see issues where the second a customer tries to login, okta throws an error because it thinks the token is already expired immediately. These are cases where the customer’s computer clock is an hour or so off from real time.