Reinstate ClockService

[lwansbrough]

The clock service was removed for (unknown to me) reasons. A clock service (and accompanying serverside time API) is required for large scale applications as incorrect user clocks are not uncommon. When the clock is incorrectly set on the client, the user is unable to sign in and there are no server side errors to indicate that there may be a problem.

Examples where clock skew occurs due to an incorrect client side clock, where the clock is still "correct" in terms of wall clock time:

• Incorrect DST settings
• Incorrect timezone settings
• Incorrect 12 hour clock (AM/PM switched by user error)

[pamapa]

The removed clock service did this:

export class ClockService {
    getEpochTime() {
        return Promise.resolve(Date.now() / 1000 | 0);
    }
}

The refactor simplified the code to directly use Date.now() / 1000. Thus that would not help you...

One common practice for cases where the time is not accurate enough is clock skew settings on the back-end side. But that does not deal with timezones. I am open to extend this library with a working ClockService solution. Best to start with the design idea...

[brockallen]

The refactor simplified the code to directly use Date.now() / 1000. Thus that would not help you...

In oidc-client-js, people used it to make a server-side call to get the correct time.

[pamapa]

In oidc-client-js, people used it to make a server-side call to get the correct time.

Thanks for helping. I am unaware of that feature, can you give me a link to the code function implementing this? How did this work?

[brockallen]

Thanks for helping. I am unaware of that feature, can you give me a link to the code function implementing this? How did this work?

Customers wrote that code (not me). Just give people a way to make an async call to get the time -- that's it (and that was the point of the service). It doesn't have to be a service -- could just be a callback on some options somewhere.

[lwansbrough]

FYI the prior clock service code was incomplete. Sometimes the library would not use the clock service when it should have. Be sure all instances where Date.now() is called are replaced.

[pamapa]

Ok, i thought that was intentional. Is there a specific reason to have the getEpochTime return a Promise, returning number makes it much simpler...

[lwansbrough]

It's asynchronous to allow users to make a network call if necessary (which is the primary use case.) However, you could have a single async initialization method to get the time offset from the server, then subsequent calls to getEpochTime could use the offset without making an API call.

For instance, the server returns a UTC timestamp. The client then compares its Date.now() UTC time to the server timestamp to get the skew, and applies that skew to the local Date.now() on subsequent calls to getEpochTime.

[pamapa]

@lwansbrough Does https://github.com/authts/oidc-client-ts/pull/416 work for your case?

[tobiaszuercher]

having an app that is used worldwide: it's insane how much wrong clocks are around. timezone makes it even more difficult. we ended also up calling our own backend for the client, since there was no way to rely on the clients clock.

we'd like to migrate to oidc-client-ts, but without the clock feature not possible. if there is anything i can help, ping me!

i strongly believe that a clockservice (with async) needs to be in for any serious app. telling user to fix their clock shouldnt be a solution.

anyway: thank you a lot for picking up oidc-client!

[pamapa]

My first attempt, which is parked on a MR made everything extremely complicated. As i now better understand the needs i would suggest to allow to replace the "default" ClockService by a custom one. That injecting of the custom ClockService must be done globally. Similar like we have for the logging feature. Which means if you have multiple UserManager instances it changes for all of them. Should be good enough...

@kherock What do you think?

[pamapa]

What i forgot in the previous post: Since we have dropped the implicit grant, we do no longer need to validate the token. The expires time we receive from the auth request is in seconds and not a time. Thus i am not really sure that the timezone thing is an issue anymore. As long as the client has a more or less accurate clock it should work.

The predecessor library needed for the implicit grant jwt validation code using time and clock clockSkew. That code was bound to timezones. This code is no longer present in this library.

@tobiaszuercher Please double check that you need a ClockService and explain why...

If somebody really really needs a ClockService, we can do so, but i would like to understand the need/use case first.

[longsleep]

@pamapa i agree - the time/clock on the client should not matter as all client code retrieves relative durations (e.g. expires_in).