-
Notifications
You must be signed in to change notification settings - Fork 222
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
Comments
… 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
… election Introduces leader election for concurrent token refresh requests. Gracefully falls back when Web Lock API is not available. Closes authts#430
… election Introduces leader election for concurrent token refresh requests. Gracefully falls back when Web Lock API is not available. Closes authts#430
… election Introduces leader election for concurrent token refresh requests. Gracefully falls back when Web Lock API is not available. Closes authts#430
@DASPRiD Would be really cool if you can find some time in the next few weeks to fix this. |
Hi, just wondering what’s the status for this issue? It is a much needed feature. |
the implementation stuck, there is a good starting point here in MR #434, but there are some review comments which must be resolved first... |
Hi, just wondering what’s the status for this issue? It is a much needed feature. |
The implementation stalled, see MR #434. Would be excellent if somebody would take up that... |
My current solution is to disable the refresh token revoke policy, but this reduces security. I am very eager to have this issue resolved |
@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 -
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 |
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? |
@lomboboo I thought google abandoned third-party cookie phaseout... |
@pamapa They're constantly moving the "final" date, but I do think this is where everything is headed eventually. |
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.
The text was updated successfully, but these errors were encountered: