Refresh Token issue with multiple tabs open

[DASPRiD]

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]

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

[CobusKruger]

@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]

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...

[felixfirefighter]

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

[pamapa]

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]

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

[pamapa]

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

[Lucklj521]

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]

@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