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

Refresh Token issue with multiple tabs open #430

Open
DASPRiD opened this issue Mar 18, 2022 · 12 comments · May be fixed by #434
Open

Refresh Token issue with multiple tabs open #430

DASPRiD opened this issue Mar 18, 2022 · 12 comments · May be fixed by #434
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@DASPRiD
Copy link
Contributor

DASPRiD commented Mar 18, 2022

When a user has multiple tabs of an application open, and the refresh token is stored in either the session- or the local storage, both windows will try to use the refresh token at the same time.

This is an issue when the OIDC server uses refresh token rotation (which is a requirement to be able to store refresh tokens on the client), as whichever request goes through after the first will fail due to a deactivated refresh token.

The OIDC client should create a lock in the storage, so only one client does perform the refresh, while the other clients wait for the result of that client.

@pamapa pamapa added bug Something isn't working help wanted Extra attention is needed labels Mar 21, 2022
DASPRiD added a commit to DASPRiD/oidc-client-ts that referenced this issue Mar 22, 2022
… election

Introduces leader election for concurrent token refresh requests. This adds a
new dependency (broadcast-channel) which takes care of the election process.

Closes authts#430
DASPRiD added a commit to DASPRiD/oidc-client-ts that referenced this issue Mar 25, 2022
… election

Introduces leader election for concurrent token refresh requests. Gracefully falls
back when Web Lock API is not available.

Closes authts#430
DASPRiD added a commit to DASPRiD/oidc-client-ts that referenced this issue Mar 25, 2022
… election

Introduces leader election for concurrent token refresh requests. Gracefully
falls back when Web Lock API is not available.

Closes authts#430
@pamapa pamapa added this to the 2.0.3 milestone Mar 25, 2022
DASPRiD added a commit to DASPRiD/oidc-client-ts that referenced this issue Mar 25, 2022
… election

Introduces leader election for concurrent token refresh requests. Gracefully
falls back when Web Lock API is not available.

Closes authts#430
@pamapa pamapa modified the milestones: 2.0.3, 2.0.4 Apr 6, 2022
@pamapa pamapa modified the milestones: 2.0.4, 2.0.5 May 11, 2022
@pamapa pamapa modified the milestones: 2.0.5, 2.0.6 Jun 13, 2022
@pamapa
Copy link
Member

pamapa commented Jun 17, 2022

@DASPRiD Would be really cool if you can find some time in the next few weeks to fix this.

@CobusKruger
Copy link

@DASPRiD and @pamapa I see several commits related to this issue, but it's also been pushed to milestone 2.0.6. Do we know what the state of this issue is, and whether it will be in 2.0.6?

@pamapa
Copy link
Member

pamapa commented Aug 30, 2022

The development process is driven by @DASPRiD , but currently on hold because he had no time to finish. The way to implement should be agreed on. See MR #434. Would be nice if this can be finished sometime this year...

@pamapa pamapa modified the milestones: 2.0.6, 2.0.7 Sep 5, 2022
@pamapa pamapa modified the milestones: 2.1.0, 2.2.0 Oct 17, 2022
@pamapa pamapa removed this from the 2.x.0 milestone Mar 17, 2023
@felixfirefighter
Copy link

Hi, just wondering what’s the status for this issue? It is a much needed feature.

@pamapa
Copy link
Member

pamapa commented Oct 18, 2023

the implementation stuck, there is a good starting point here in MR #434, but there are some review comments which must be resolved first...

@timurscribe
Copy link

Hi, just wondering what’s the status for this issue? It is a much needed feature.

@pamapa
Copy link
Member

pamapa commented Mar 21, 2024

The implementation stalled, see MR #434. Would be excellent if somebody would take up that...

@Lucklj521
Copy link

Lucklj521 commented Aug 8, 2024

My current solution is to disable the refresh token revoke policy, but this reduces security. I am very eager to have this issue resolved

@rahul-sharma-uipath
Copy link

rahul-sharma-uipath commented Aug 16, 2024

@pamapa one idea - given that there are 2 ways to silently refresh (e.g. silent sign in with prompt=none and via a refresh token) I believe we can do the following -

  • on first load of the application, don't store the refresh token, or delete if it exists (tracked with an in memory flag)
  • this will enforce that if a tab is duplicated, on first load it will never try to use the same refresh token
  • on subsequent refreshes, we let all tabs follow the standard refresh token flow, and there's a guarantee that it will not conflict

the underlying issue is that a lock or broadcast channel based solution will never work, simply because the problem isn't that the refresh happens at the same time, but rather the fact that will always conflict with each other given an IDP that doesn't allow duplicate refresh tokens. In light of that, IMO the above is the simplest solution, since there is no complicated/potentially flaky logic to elect a leader or similar

@lomboboo
Copy link

lomboboo commented Dec 9, 2024

Are there any active development on this? With Google planning to block 3-rd party cookies soon it seems like iframe silent renew will be dangerous to use.

Curious what is the priority on this, is it in the pipeline to be fixed soon?

@pamapa
Copy link
Member

pamapa commented Dec 10, 2024

@lomboboo I thought google abandoned third-party cookie phaseout...

@lomboboo
Copy link

@pamapa They're constantly moving the "final" date, but I do think this is where everything is headed eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
8 participants