Oidc-client-js: Exp is in the past

[jeanpoelie]

Info
Made this ticket first in the identityserver project but moved it to this repository. https://github.com/IdentityServer/IdentityServer4/issues/4291

Issue / Steps to reproduce the problem
Some of our users are experiencing problems with logging in, the logging reports that:
Error: exp is in the past: [time]

We have been able to reproduce this fully.
A user who has a different timezone (read, Amsterdam, London, Sydney etc.) will not have this error occuring because the time is converted to UTC.
A user who lives in The Netherlands currently has a time of 13:15.
They change their time manually (ignore the phone setting for network timezone) will set a time by hand, but they actually do not change the time, keep it at 13:15.
The time on the server is in UTC, and is current 11:15.
Normally this would match because Timezone Europe/Amsterdam is +2 in UTC at this moment.
But because the user turned of network syncing it seems to think that 13:15 is the UTC time, therefore the user will have a exp in the past.
This also works for aic is in the future (same steps).

We reproduce this 100% of the time, now this either seems to be a bug for the phones, which would make it irrelevant here, or, it is a bug that the library does not keep in mind that a user can remove syncing.

I feel like this should be investigated a bit to see if we can get a users timezone even though they turned of their time syncing.

[brockallen]

This has been asked before... the spec says how to validate the token expiration, so not sure what to say. If the UTC logic in the browser is off of the timezone/clock is wrong in the browser, then not much the library can do.

[roddy]

We're seeing this too, but due to clock drift on the server so that while the browser has a correct UTC offset, the timestamp being returned by the server is off.

It almost seems like we need some way to do a handshake between the browser and the authentication server before we initialize the oidc client in order to figure out how badly out of sync we are, and then have custom logic in place to verify against what the server thinks is current time and not what the browser thinks it is.

[brockallen]

Unfortunately that's not covered in the OIDC spec. It's written to assume clients and servers have some way to sync their own clocks.

[jeanpoelie]

Have you come by this challenge before? I have read the other issues but none had a solution, currently i see only 2 logical options:

1. Handshaking the time with a serverside api before logging in, if it fails, show an error (as mentioned by roddy)
2. Check the device time from the browser before sending for example inside the oidc library. But i am not sure a browser is allowed to get such data.

[brockallen]

We might be seeing a PR soon that helps with this.

[olivergrimes]

I experienced this error message due to a time-synchronisation issue on Docker Desktop (Windows). This blog post documents the issue well.

As it's my development environment, I just set a large clockSkew in the UserManagerSettings for local development.

[modmoto]

Hi, we experience this issue aswell and it creates some nasty issues where we do not have a good way of handling these problems gracefully. I mean showing the user a message like "please change your local time to xyc to be able to log in" is pretty weird. I also understand that validating against the spec is needed, but we would need this PR aswell (however the solution might look like).

Is there something we can assist here?

[brockallen]

Yes, there was a PR recently to allow you to implement the time func.

[modmoto]

Ok nice, is this in the latest release? Could not find it while browsing through closed prs or the documentation. Gotta check that out tomorrow on pc.

Anyway, thanks a lot for your effort :D