Authentication fails when the Auth popup window removes `window.opener`

[MTG2000]

Describe the bug
We are using WorkOS authkit for our MCP server authentication, and it seems like whenever the auth flow window is opened, it removes the value of window.opener (likely for as a security measure). So when the auth flow is completed and the onMcpAuthorization callback is called, it will reach this line and fail:

use-mcp/src/auth/callback.ts

Line 75 in 8952e3b

if (window.opener && !window.opener.closed) {

Expected behavior
I imagine that not only WorkOS would be removing the value of window.opener, so it's likely better to use a more reliable communication method that would always work.

For example, using localStorage + polling might be more reliable and still provide very similar behaviour to the current API I imagine? (Meaning instead of the onMcpAuthoriazation callback function trying to communicate directly with the original window using window.opener.postMessage, it can insert the result in a localStorage queue/cell, and the original window would be polling this same queue/cell for new entries & processing them when it finds any.

Of course there's a bit of extra overhead with this approach, but I believe it should be more reliable with different auth providers?

I checked how some other MCP clients do this, and saw that most of them go about it in a similar way. (Not with window.opener)

Thanks a lot btw for your work on this useful wrapper 🙏

[MTG2000]

To give further context, this issue is not specific to AuthKit, but to any auth provider where the auth flow document returns Cross-Origin-Opener-Policy header with a value other than the unsafe-none
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy

Which is a valid measure since there are security vulnerabilities that could be exploited without it.
So I think changing the communication method in the library here would be better and ensure that it works with most auth providers.

[MTG2000]

Or even maybe a cleaner approach would be using the Broadcast Channel API: https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API

Which has a very similar api to window.postMessage, so the code changes would be minimal & the final behaviour should remain the same