Microsoft 365 OAuth: popup reports "account connected" but parent window shows "Authorization pop-up closed" and no account is created

[bentpurist]

Steps to reproduce

1. Configure Microsoft OAuth in Groupware → Microsoft Integration (Client ID, Secret, tenant common). Confirmed saved and persisting after a hard reload of the admin page.
2. Azure app registration: redirect URI is an exact, character-for-character match to https:///index.php/apps/mail/integration/microsoft-auth, registered under the Web platform (not SPA). Admin consent granted successfully.
3. In the Mail app, add an account via the Auto path (email + placeholder password) → Connect.
4. Complete sign-in and consent in the Microsoft popup; the popup reaches "Account connected / you can close this window."

Expected behavior

The account is created and the mailbox loads.

Actual behavior

While the Microsoft popup is still open and showing success, the underlying account-setup box in the parent window already displays "Authorization pop-up closed." After closing the popup, the Mail app returns to the login screen with no account in the sidebar — the account is never created. This appears similar to the symptom in issue #9159.

Mail app version

5.9.1

Nextcloud version

33.0.5

Mailserver or service

Microsoft 365 / Exchange Online (XOAUTH2)

Operating system

Linux

PHP engine version

Other

Nextcloud memory caching

No response

Web server

Apache (supported)

Database

MySQL

Additional info

Browser: Reproduces in Microsoft Edge with a clean/default profile, third-party cookies and popups allowed for the Nextcloud domain and login.microsoftonline.com. Also reproduces in Chrome.
Hosting: Managed Nextcloud (Cloudamo) — I do not have shell/occ access, and the in-browser admin log viewer shows no entries.

Additional context / already ruled out: Credentials are in the correct Mail-app panel (redirect URI path is /apps/mail/), saved server-side. Azure redirect URI is an exact match and registered as Web, not SPA. IMAP is enabled on the mailbox; admin consent succeeded after elevating the Azure role. Browser-side causes ruled out via clean Edge profile with cookies/popups allowed.

Given the "Authorization pop-up closed" message appearing before the popup completes, is this a known front-channel/callback handling issue, and what server-side configuration (e.g. overwrite.cli.url, overwriteprotocol/overwritehost, trusted_domains, or reverse-proxy rewriting of the /index.php/apps/mail/integration/microsoft-auth path) would cause the parent window not to receive the popup's result? I'm on managed hosting and would like to give the host a precise instruction if this is on their side.

[bentpurist]

Possible root cause: COOP header on login.microsoftonline.com breaking the popup signaling

After more digging, I believe this is caused by Microsoft deploying Cross-Origin-Opener-Policy: same-origin on login.microsoftonline.com (discussed here: https://learn.microsoft.com/en-us/answers/questions/5790872/popup-login-flow-not-working-since-microsoft-block). When that header is enforced, the browser performs a browsing context group switch as soon as the popup navigates to Microsoft's login page. This permanently severs window.opener — even after the popup redirects back to the Nextcloud origin.

That breaks both signaling mechanisms in src/integration/oauth.js:

The 200ms interval polling ssoWindow.closed returns true once the BCG switch happens, so the parent rejects with OAUTH_CONSENT_ABORTED ("Authorization pop-up closed") while the popup is still open and mid-login. This matches my symptom exactly — the parent shows the error before the popup completes.
The callback page's postMessage('DONE') never arrives, because window.opener is null in the popup by that point.

This would also explain why it reproduces across browsers (it's spec-mandated COOP behavior, not a cookie/popup setting) and why it isn't fixable via overwrite.cli.url, proxy config, or Azure settings. Microsoft's rollout appears staged (some responses still show Cross-Origin-Opener-Policy-Report-Only), which may explain why some installs still work.
Suggested fix: replace the window.opener + closed-polling mechanism with a BroadcastChannel. Since the callback page (/apps/mail/integration/microsoft-auth) lands on the same origin as the parent window, a BroadcastChannel message gets through regardless of the cross-origin detour, and popup.closed no longer needs to be trusted. osm-auth fixed the identical breakage this way: osmlab/osm-auth#138

Happy to test a patched build.

Note: I checked the browser console during the flow and saw no COOP warning — consistent with the header being enforced (the "would block" warnings typically appear only in report-only mode). The premature "pop-up closed" while the popup is still open remains the key observable symptom.

[ChristophWurst]

because window.opener is null in the popup by that point

Have you been able to verify that?

[ChristophWurst]

Thanks for the report. This sounds like it could be the issue but I'd like to get proof first

[bentpurist]

Yes — verified. With the popup left open on the "Account connected, you can close this window" screen (so it's back on the Nextcloud origin), I opened DevTools on the popup and evaluated window.opener in the console. It returns null.
So by the time the callback page is reached, the opener reference is already gone, which is why the postMessage('DONE') can't reach the parent and why the parent's ssoWindow.closed poll trips OAUTH_CONSENT_ABORTED prematurely. Consistent with the COOP browsing-context-group switch on login.microsoftonline.com severing the opener for the rest of the popup's lifetime.
Happy to run any other checks or test a patched build.