Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deal with users having a system time in the future? #1373

Open
fwolff opened this issue May 22, 2024 · 1 comment
Open

How to deal with users having a system time in the future? #1373

fwolff opened this issue May 22, 2024 · 1 comment

Comments

@fwolff
Copy link

fwolff commented May 22, 2024

Issue and Steps to Reproduce

When you set your system date / time in the future, two things can happen:

  • if the delta between your time and the server (Azure in my case) time is more than the expiry of the access token, the application is caught in an infinite loop trying to get a token that is not immediately expired.
  • if the delta is more than the refresh_time_before_tokens_expiration_in_second, the user can send an expired token to the server before it is automatically refreshed.

I couldn't find any way to tell the user that his system time isn't sync with the server time and that it should adjust it.

Versions

7.22.4 with a service worker

Expected

Give a way to tell the user that his system time isn't sync with the server time and that he should adjust it.

Actual

See "Issue and Steps to Reproduce" above.

Additional Details

My configuration:

export const oidcConfiguration: OidcConfiguration = {
    client_id: "***",
    redirect_uri: '***/authentication/callback',
    silent_redirect_uri: '***/authentication/silent_callback',
    scope: 'openid profile email',
    authority: "***",
    service_worker_relative_url: "/OidcServiceWorker.js",
    service_worker_only: true,
}
@guillaume-chervet
Copy link
Contributor

Hi @fwolff very sorry for the delay.

System in general are synchronised.
There is no way to check it.

If you have that case you can renew token when an http 401 occured.
I think it is the best way to handle that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants