Best practices for a custom clockService

[magoogli]

Hi,

I have a SPA which is using the oidc-client, and have experienced similar issues as discussed here: #472 and here: #1108 where the client has incorrectly configured their time and is unable to log in due to token validation failure. The SPA is used by hundreds of different users on different devices, and telling the them to fix their time is frustrating, and the issue will just escalate as new users sign up. From a technical perspective I understand why it doesn't work, but users don't really care and in general just want the web app to work even if their time is incorrect.

I see that recently a 'clockService' was added that can be configured in the oidcClientSettings, and looking at the code this seems to be a way of customizing what time source is used when validating the token. So my idea is to simply create an unauthenticated endpoint on our back end Identity Server which serves up the current system time, and have a custom clockService in the client call this to get the time instead of using their local time.

Would such an approach be appropriate, or is there a better way? I don't want to compromise security in any way or open up endpoints without authentication unnecessarily. Any advice or suggestions for best practices in this regard would be appreciated.

[brockallen]

but users don't really care and in general just want the web app to work I don't want to compromise security in any way

Those two above statements seem to be conflicting requirements :) The clock check is part of the required validation steps in OIDC. I don't know what else to say about it.

Would such an approach be appropriate

Yea, that's the general intent with the extensibility point.

[magoogli]

Ok, thanks for the speedy reply. I will implement a new endpoint on the backend then to get the time of the server and validate based on that.