This repository was archived by the owner on Mar 16, 2025. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation of the popup-based web OAuth handoff is broken on browsers that enforce a same-origin COOP policy (cross origin opener policy) since the window.opener value in the spawned popup will be null and the parent's access to the window.closed as described here: https://web.dev/why-coop-coep/#coop. The current implementation in this lib relies on an onMessage event from the popup which similarly is blocked by COOP.
This means that the opener has no way of knowing when the Oauth redirect has occurred and can not access the code returned from the OAuth handoff in order to finish the flow.
This security feature has shipped and is the default behavior in major browsers like Chrome and Firefox as noted here https://bugs.chromium.org/p/chromium/issues/detail?id=1221127 and I've run into this problem firsthand using oauth2_client in Chrome.
I don't have a great fix at this time, the only thing that has worked for me is to use localStorage to pass the code between the popup and the opener but I recognize that storing sensitive data in local storage like the Oauth code is a vulnerability for any malicious JS code that can access it on your domain. I've held off on shipping anything to a production app until I can get a read from folks on if there is a better alternative.
Let me know what people think, I'm interested in exploring the solutions here further.
Thanks