The Effect of System Clock Skew on Okta Authentication Flows
Last Updated:
Overview
Time discrepancies, or clock skew, between a local system and the Okta server affect token validation during authentication flows. When the system clock is behind, the maxClockSkew property determines validation success, whereas a system clock that is ahead depends on the ID token lifetime. If the system clock is too far ahead, Okta generates the following error:
"The JWT was issued in the future"
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Okta Sign-In Widget
- okta-auth-js Library
- Token Validation
- System Clock Skew
Solution
How does a system clock set behind server time affect token validation?
When the local system clock is behind the Okta server time, the maxClockSkew property in the okta-auth-js library dictates the validation behavior. This property configures the maximum allowed difference, in seconds, between a client clock and the server clock. Review the following behaviors when the system clock falls behind the server time.
- The default
maxClockSkewvalue is 300 seconds (five minutes). - Token validation succeeds if the system time is behind the server time but remains within the configured
maxClockSkewrange. - Token validation fails if the time deviation exceeds the configured range.
- The
maxClockSkewproperty only affects validation when the system clock is behind the server time and does not apply when the system clock is ahead.
How does a system clock set ahead of server time affect token validation?
When the local system clock is ahead of the Okta server time, the validation check depends on the ID token lifetime. The default ID token lifetime is 60 minutes. Review the following behaviors when the system clock advances past the server time.
- Token validation succeeds if the system time advances to a point within the 60-minute ID token lifetime window.
- Okta triggers a "The JWT was issued in the future" validation error if the system time is more than 60 minutes ahead of the server time.
