invalid_grant error during token refresh with clock skew

OAuth 2.0 implementations rely on the Authorization Server to validate the exp claim of a token using Unix timestamps. While the standard dictates UTC-based timing, discrepancies between the client system clock and the server clock can lead to synchronization issues.

When a client attempts to use a refresh token that is marginally close to its expiration window, clock skew may cause the server to perceive the token as expired before the client does. This results in the server returning an invalid_grant error, despite the client's local time indicating the token is still valid.

There is currently no universal standard for the amount of leeway or grace period an Authorization Server should provide to account for this drift.

• What is the industry-standard window for acceptable clock skew before an invalid_grant is triggered?
• How can a client programmatically determine the server's time offset to prevent premature expiration errors?