Unable to connect Microsoft email account to Mail

ℹ️ Support
,
1

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 33.0.5
  • Operating system and version (e.g., Ubuntu 24.04):
    • Linux
  • Web server and version (e.g, Apache 2.4.25):
    • Apache 2.4.67
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • Unknown
  • PHP version (e.g, 8.3):
    • 8.5
  • Is this the first time you’ve seen this error? (Yes / No):
    • It has been repeated many times.
  • When did this problem seem to first start?
    • When trying to log into the Mail app.
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Unknown
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

I am trying to connect my Microsoft 365 / Exchange email account hosted by Azure to my Nextcloud instance hosted by Cloudamo. I enter my name, email address and password in the log-in screen. It then authenticates with Microsoft which confirms the connection in a pop-up window. At the same time, a message appears below my password saying that the pop-up window closed (it was still open). The log-in screen remains and the Mail app does not move on to the list of emails. According to Claude Opus 4.8 (high), “‘[a]uthorization pop-up closed’ appearing in the main window while the popup is still open means the main window has lost its connection to the popup prematurely. The two windows communicate during the handoff, and the parent is concluding the popup is gone before the popup has actually delivered its result back. So even though the popup itself reaches “you can close this window,” the main Mail window already gave up waiting — which is exactly why you land back on the login screen with no account. The success the popup reports never gets received by the app. This pattern is a known signature: the popup status moves to “Authorization pop-up closed,” yet the popup itself completes and says the account is connected and the window can be closed — and still nothing happens to actually log you in.”

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:

  1. 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.
  2. 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: fix popup auth broken due to new COOP header by k-yle · Pull Request #138 · osmlab/osm-auth · GitHub

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.

Steps to replicate it (hint: details matter!):

  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://<my-domain>/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.”

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

I do not have access to the logs.

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

N/A

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

I do not have access to the logs.

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

I do not have access to the logs.

Apps

The output of occ app:list (if possible).

Tips for increasing the likelihood of a response

  • Use the preformatted text formatting option in the editor for all log entries and configuration output.
  • If screenshots are useful, feel free to include them.
    • If possible, also include key error output in text form so it can be searched for.
  • Try to edit log output only minimally (if at all) so that it can be ran through analyzers / formatters by those trying to help you.