Popup Login flow not working since microsoft blocked windows opener unexpectedly

Question

Popup Login flow not working since microsoft blocked windows opener unexpectedly

Anonymous

We are facing issues with https://login.windows.net/common/OAuth2/authorize?resource=https://manage.office.com since the resource is giving response header as cross-origin-opener-policy : same-origin; report-to="coop-endpoint"due to which window.opener is not working and after successful redirection with microsoft we are unable to get back the auth code back to platform using window.opener.postMessage, this issue causing the popup window to hang and blocking the whole authorization flow

cross-origin-opener

User's image

0 comments

3 answers

Your answer

Answer 1

Yuri Leontyev 0

In our case (started in *.sharepoint.com and ended in yourcompany.com) we've implemented a proactive solution to the possible issue in future with Server Sent Events:

open SSE connection to WebAPI for the action
open popup to login
login through Entra ID
redirect back to process the action in WebAPI
close the popup
send results to the page using SSE

More details - https://medium.com/@yuri.leontyev/recently-we-got-a-strange-issue-that-sometimes-entra-id-login-popup-was-not-closing-8c1d417472af

0 comments

Answer 2

Andrea Santi 15

TL;DR

Use BroadcastChannel instead of window.opener — fix is in the last code block below.

(I want 2 days of my life back.)

We ran into the exact same issue and spent two days debugging it. Here is what we found and the fix that actually works.

Microsoft silently deployed Cross-Origin-Opener-Policy: same-origin on login.microsoftonline.com. Still visible in Report-Only mode today (Cross-Origin-Opener-Policy-Report-Only: same-origin). When enforced, the browser does a Browsing Context Group (BCG) switch the moment the popup hits Microsoft's login page — and that permanently kills window.opener. Not temporarily. Permanently. Even after the popup navigates back to your own domain.

The answer above by suggesting window.opener.postMessage() from your redirect page doesn't work for exactly this reason. The BCG switch doesn't reverse on navigation away from Microsoft's domain — it triggers a second one. opener stays null. @Yuri Leontyev @Robert Tucker-Bays The only thing that works is BroadcastChannel — it doesn't use window references at all:

// popup
const ch = new BroadcastChannel('auth-callback');
ch.postMessage({ type: 'AUTH_SUCCESS', token });
ch.close(); window.close();

// parent
const ch = new BroadcastChannel('auth-callback');
ch.onmessage = (e) => { if (e.data?.type === 'AUTH_SUCCESS') { ch.close(); /* ... */ } };

Supported in every modern browser since ~2016, COOP-immune by design.

To whoever at Microsoft is reading this: you canary-deployed a breaking change to a production identity provider with no changelog, no deprecation notice, nothing. Users got locked out of production systems. We spent two days looking for the bug in our own code. "Report-only" is not communication — it's a header that developers see only if they happen to be staring at DevTools at the right moment.

When you enforce this, please put a notice somewhere. The 2 days of my life spent debugging it are already gone — at least spare the next person.

Yuri Leontyev 15 Reputation points

2026-03-05T11:50:50.63+00:00

Unfortunately, BroadcastChannel will not work for us as it's same origin only and we are on different.
Robert Tucker-Bays 10 Reputation points

2026-03-05T11:54:23.45+00:00

it also doesn't work for us since officeJS apps are in an iframe on outlook.office.com and so storage partitioning prevents them from communicating even though they're the same origin
Andrea Santi 15 Reputation points

2026-03-05T11:55:30.2566667+00:00
In our case the popup starts and ends on our own origin — the different-origin part (Microsoft's login page) is just a stop in the middle.

Our flow:

Parent opens popup → https://ourapp.example.com/assets/reauth-popup.html (same origin)

Popup triggers Keycloak, which redirects to login.microsoftonline.com (different origin, COOP fires here)

User authenticates, Microsoft redirects back to Keycloak, Keycloak redirects back to https://ourapp.example.com/assets/reauth-popup.html (same origin again)

Popup sends BroadcastChannel message — both sender and receiver are on ourapp.example.com

Since BroadcastChannel only needs to be same-origin between the sender (popup, after it lands back on your domain) and the receiver (parent window). It doesn't matter that the popup visited a cross-origin page in between.

If your redirect URI lands on a different origin than your parent window, then yes, BroadcastChannel won't help. In that case I'm afraid you'd need to either align the origins, or use a different approach entirely (e.g. a full redirect flow with state serialization).
Yuri Leontyev 15 Reputation points

2026-03-05T12:11:37.6266667+00:00

@Andrea Santi Yes, we understand. But for us it started working correctly again today. Looks like the change is reverted. We're currently implementing a temporary fix just to close popup or display error details there. We do not need anything from there (like token), just need to know the process ended.

The issue with aligning on same origin is that our parent page is sharepoint.com and we can't do much. We plan to try uploading an html page with some JS to a library and see if it can serve as end on the same origin, but not sure it'll work.
Nehe, Bhushan 0 Reputation points

2026-03-12T13:21:44.58+00:00

All, Is there an official communication on the header change and can someone confirm if its reverted
Anonymous

2026-03-13T05:27:17.6366667+00:00

Hi @Nehe, Bhushan
There’s no separate formal announcement on a header change; however, MSAL.js v5 documents COOP handling via the redirect bridge pattern, which is the supported mitigation when COOP headers are present.

You can refer to microsoft-authentication-library-for-js/lib/msal-browser/docs/v4-migration.md at dev · AzureAD/micr…

Answer 3

Anonymous

Hi @Collection Team

Thank you for posting your question in the Microsoft Q&A forum.

Please note that our forum is a public platform, and we will modify your image to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

You’re running into a browser security change, not an OAuth issue. When Microsoft login pages send the header Cross-Origin-Opener-Policy: same-origin; report-to="coop-endpoint", modern browsers place that page in a separate browsing context group. As a result, window.opener is intentionally set to null for cross-origin popups, so calls like window.opener.postMessage(...) stop working after the redirect from login.windows.net or login.microsoftonline.com.

This behavior is enforced by the browser as part of the Cross-Origin-Opener-Policy (COOP) specification and cannot be overridden by your application.

Here are some options you may consider:

1.Use redirect flow instead of popup

-Redirect the main window with window.location.href = authorizeUrl .

-User signs in on Microsoft’s domain.

-Microsoft redirects back to your redirect URI.

-Your app reads the authorization code from the query string.

-Exchange the authorization code for tokens.

-This avoids window.opener entirely.

2.Use redirect + postMessage from your own redirect page.

If you must keep a popup-based experience:

-Set your redirect URI to a page you control, e.g. https://yourapp.com/auth-callback.html.

-After Microsoft completes authentication, it redirects the popup to that page.

-Since the page is now on your domain, it can safely execute:

window.opener.postMessage(authData, "https://yourapp.com");  
window.close();

Important notes:

-The postMessage must originate from your domain, not from Microsoft’s login domain.

-The redirect page must not send a restrictive COOP header (such as Cross-Origin-Opener-Policy: same-origin), otherwise window.opener will remain unavailable.

-The popup must not be opened with noopener, as that also nullifies window.opener.

-The redirect page must be same-origin with the parent window.

Once the popup navigates away from Microsoft’s isolated page and loads your same-origin redirect page (without COOP isolation), the opener relationship can be available again, allowing postMessage to succeed.

I hope this helps clarify the behavior and available options.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Anonymous

2026-03-01T23:38:05.6333333+00:00

Hi @Collection Team
May I know if you have got any chance to check my answer? If you need further assistance, please feel free to let me know. Thank you!
Robert Tucker-Bays 10 Reputation points

2026-03-03T09:21:23.4433333+00:00

Hi @Anonymous ,

Not the original poster, but my team is also having the same issue sporadically since yesterday morning. We're using an officeJS addin, and have been using a popup for SSO auth for the last 4-5 years due to the main office JS taskpanes in outlook needing to remain in a single domain.

We already use window.opener.postMessage() to communicate back to the main app after authentication, however since yesterday morning we have had had window.opener remaining null even after SSO flow completes and redirects back to our domain.

The main app also keeps reference to the popup using var ssoWindow = window.open(....), and tracks ssoWindow.closed to see if the user backs out. This value is now returning true as soon as the popup navigates to the microsoft auth flow, indicating that the window has been closed (This is new behaviour).
Anonymous

2026-03-04T07:03:19.0433333+00:00

Hi @Robert Tucker-Bays
What you’re seeing is consistent with the same COOP (Cross‑Origin‑Opener‑Policy) browser enforcement described above, and it explains both symptoms you mentioned.

This behavior is enforced by the browser as part of the COOP specification and cannot be worked around with application code that relies on window.open / window.opener once the popup has navigated to Microsoft login pages.

This isn’t an OAuth or Office.js regression. It’s a browser security change that started rolling out recently and any solution that depends on window.opener or popup.closed will no longer be reliable once the popup navigates to Microsoft’s identity endpoints.

May I know if you had a chance to try the above suggestions?

Or move to the Office Dialog API Use Office.context.ui.displayDialogAsync() and communicate results back with Office.context.ui.messageParent(). This runs in a host‑managed dialog and avoids relying on window.open, window.opener, or browser popup lifecycle semantics.
Robert Tucker-Bays 10 Reputation points

2026-03-04T07:21:01+00:00
Hi @Anonymous

I've tried all of the above with no luck. The issue is currently intermittent, which I assume is because the browsers are soft launching the update.

Redirect flow doesn't work for office js because because the main app is restricted to a single domain (ours) and is also in an iframe which gets blocked from sso

Popup flow with a redirect doesn't work because the coop header kills the relationship to the opener

The officejs dialogasync doesn't work because that window is also an iframe in web outlook which blocks sso flow

I've also tried using local storage polling to save and read the token once returned but due to coop contexts, the main window doesn't share this with the opener either.
Anonymous

2026-03-05T06:45:13.67+00:00
Hi @Robert Tucker-Bays
Thanks for the update.

What you’re seeing is consistent with browsers enforcing COOP. Once the popup navigates to Microsoft identity endpoints, the browser moves it into a separate browsing context group, intentionally severing the window.opener relationship. As a result, mechanisms that rely on that relationship such as postMessage, popup lifecycle tracking, or storage-based polling between the windows can become unreliable or stop working.

This behavior is caused by modern browser security enforcement rather than an OAuth or Office.js regression. Traditional popup patterns that depend on maintaining the window.opener relationship across identity provider pages are therefore no longer reliable.

In Outlook (web/new), add-ins run inside iframes with single-origin constraints, which further limits how interactive authentication flows can be implemented inside the task pane. Because of this, legacy approaches based on window.open, shared browser state, or window.opener can break once Microsoft identity pages are involved.

You may consider these options:

Office-native SSO using OfficeRuntime.auth.getAccessToken.

Office Dialog API (Office.context.ui.displayDialogAsync) for interactive authentication flows, returning results to the add-in via messageParent rather than relying on window.opener.

Popup flows that rely on maintaining the window.opener relationship across identity provider pages are increasingly unreliable under modern browser security enforcement.
Robert Tucker-Bays 10 Reputation points

2026-03-05T08:21:15.3666667+00:00
Hi @Anonymous ,

The first option limits you to using the current mailbox account, where we currently have users able to select accounts, or even use different SSO providers.

The second option doesn't work, because as I said in my previous comment this dialog is also an iframe which is fully blocked from performing SSO flow.

I appreciate that this is the browsers enforcing the headers that are being set by Entra for the login flow, but as far as I can see there is no way to perform SSO with any account other than the logged in mailbox.

If you have any other ideas I'd be happy to try them out, at the moment the issue is intermittent, but I can only imagine it's going to be enforced more strongly in the future.
Yuri Leontyev 15 Reputation points

2026-03-05T10:48:39.2766667+00:00

Hello @Anonymous ,

Looks like the change is reverted on the login page. We do not see the header set anymore today but it was frequently reported previous days. Could you confirm and let us know why there were no announcements about the applying the cross-origin-opener-policy header?

In our case it was working for some requests and not for others (not fully applied to all instances?).

We really had the issue with that as in our case the parent page is https://yourcompany.sharepoint.com and we execute a protected action on our backend WebApi - https://webapi.mycompany.net that requires user to re-login with MFA to confirm he is actually he. Then once the action is executed, we just notify the parent page that action is completed and possible to reload the data. We do not do the redirect on parent page and do popup to avoid losing the user focus and responsiveness - once returned back the whole SharePoint page needs to be re-loaded and user context should be restored.

Do you have any ideas how to help with our flow if change is applied again?

Thanks,
Anonymous

2026-03-06T06:26:37.6966667+00:00

Hi @Robert Tucker-Bays @Yuri Leontyev
As forum moderators, we do not have access to internal systems for deeper investigation, and due to limitations in our test environment we are unable to reproduce this issue. Our role is to provide break-fix guidance based on publicly available resources and community insights.

At the moment, I have not found any recent official documentation or community discussions that address this issue. To ensure you receive the most accurate support and avoid unsuitable suggestions, I recommend submitting a support request through Service Hub and referencing this thread. This will allow the support team to investigate further.

Please note that Services Hub is intended for paid support tickets and access is subject to certain conditions. You can find more details here Services Hub sign in FAQs | Microsoft Learn.

Thank you for your patience and understanding. We truly appreciate the effort you have taken to raise this concern.