We are using the leeway option as described here: Token was issued in the future · Issue #290 · auth0/auth0.js · GitHub
Its max value can be 60. Now there can be user whose system time is behind server clock and difference can be > 60. Some user’s faced this problem and were unable to login.
Is there any workaround for this?
The definitive solution would be to have the systems set with correct time, but like you mentioned, this is not always possible.
As an alternative, you can consider not using the default validation process of Auth0.js, which runs within the system the client application is running and as such may be out of your control, and instead parse the response (hash fragment) yourself and make a call to a server-side component running in a system that you control that makes the actual validation.
This would mean the validation would happen in a system where the time setting could be correctly setup and would work independently of how messed up is the time settings of the system running the actual client application.
For SPA, I do not think it is possible to ask all users correctly setting their computer’s clocks. Why is this check of timing necessary? When every user can set their browser’s time to any value they want, I am having a hard time understanding how this design improves the security.
Probably the most important reason is that the specification that impacts this situation and where the ID token is specified mandates the validation of token expiration which already implies that clocks need to set correctly and also considers the possibility of validating the token was not issued in the future which add another requirement for the clock to be setup correctly. Not doing so would be as if saying I want to use a know authentication protocol instead of a custom implementation to reduce risks, but then don’t want to do what the protocol recommends which would be weird.