wrong invalid token because of system time issues

In processIdToken() in the oauth-service.ts there is a check wether the token has been expired or is issued in the future. The implementation is based on new Date(), which depends on system time of the user. So when the user has a wrong system time, the promise is rejected and the hole login flow fails.

We use the library now for a while and every time a customer contacted our support, we told them to check the system time. Now we run into a special case with a user from the Canary Islands. It seems that on the Canary Islands the time is “official” one hour behind and has the time from Spain. So in this case the user has to set the “wrong” time to login.

So what I like to discuss is how useful is this check or can this be removed?

When it is done in the client, with the client time, what brings it us? I think when a token is generated the expiry date is generated with the time on the server (which can be theoretically wrong, too), so the server is the only authority which really can check the expiry. So when I do a request with a invalid token the server has to check it anyway and should response with a unauthorised status code when the token has been expired. Currently in my oppinion it makes more problems than it solves.

[jeroenheijmans]

Let’s split the issue between whether there’s a bug in the library or not, and whether checks “can […] be removed”, if that’s ok? About the first one:

The implementation is based on new Date(), which depends on system time of the user.

Hmm, don’t think it should be? I think it should be the number of milliseconds sinds the UNIX epoch. Or as this answer puts it:

if the local time is correct (for whatever time zone the computer’s set to), it should be the same in any time zone.

The iat value against which it’s being compared is a “NumericDate”, which also works with the UNIX epoch.

So I think the library should just work, if the time of a user’s computer is set correctly.

This means you could try to re-check with your users in the Canary Islands, see if their regional settings on their OS are correct (they should have (UTC +00:00) Dublin, London, ... selected I think?

In my experience, with modern software, including web applications, things can get pretty weird if clients have wrong time settings. So fixing that would probably be the best way to tackle things, if possible. However, I also know it sometimes doesn’t work that way, coming to the second part.

Is the check useful, or can it be removed?

I think it’s probably very useful, at least to me it is. Even if you’d remove the check, any timers listening for expiration (e.g. to do a silent refresh) would break down since they’d also rely on expires_at and iat.

So I don’t think removing the check is a good thing to do.

Possibly, making the check optional, via a configuration option, could help for edge cases. But that would also bloat the library with even more options and logic (as well as having possibly weird side effects on things like the refresh timers), and I’m not sure if that’s for the better.

PS. I’m not trying to invalidate your use case, and I’ve also been there with similar weird timezone issues, so I sympathize. Hopefully the above helps you figure out a good scenario. Good luck!

[bmerigan]

We also experience this issue, and while it’s technically true that the issue is the customer’s to solve, if we had an opportunity to make our software more resilient it’s good development practice to do so. Any reduction in service calls is good.