Closed Bug 2036505 Opened 5 months ago Closed 4 months ago

OAuth2 for Microsoft fails: redirectionEndpoint not defined causes http/https mismatch

Categories

(Thunderbird :: Account Manager, defect)

Thunderbird 150
defect

Tracking

(thunderbird_esr140 unaffected, thunderbird151 wontfix, thunderbird152 fixed)

RESOLVED FIXED
153 Branch
Tracking Status
thunderbird_esr140 --- unaffected
thunderbird151 --- wontfix
thunderbird152 --- fixed

People

(Reporter: uchida.yuki.mail, Assigned: jtracey, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

Steps to reproduce:

  1. Open Thunderbird 150.0.1 on Windows 11
  2. Add a new Outlook.com / Hotmail account (personal Microsoft account)
  3. When prompted, select OAuth2 authentication
  4. The OAuth2 popup opens and navigates to:
    https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
    response_type=code
    &client_id=9e5f94bc-e8a4-4e73-b8be-63364c29d753
    &redirect_uri=http%3A%2F%2Flocalhost ← HTTP
    &scope=https%3A%2F%2Foutlook.office.com%2FIMAP.AccessAsUser.All+...
  5. Complete Microsoft sign-in successfully
  6. Microsoft issues an authorization code and redirects to:
    https://localhost/?code=... ← HTTPS (upgraded by Microsoft)

Actual results:

The OAuth2 popup shows a "Connection Refused" error page at https://localhost/.
Authentication fails and the account cannot be added.

Root cause (confirmed by manual patch to omni.ja):
OAuth2Providers.sys.mjs does not define redirectionEndpoint for the
"login.microsoftonline.com" provider. Thunderbird falls back to the default
"http://localhost". However, Microsoft's identity service now redirects to
"https://localhost" (HTTPS) instead.

Because Thunderbird's URL interception waits for "http://localhost" but
Microsoft redirects to "https://localhost", the interception never fires.
Gecko then attempts to actually connect to https://localhost, which has
nothing listening → Connection Refused.

Note: Nothing is listening on localhost:80 or localhost:443 at any point.
Thunderbird uses URL interception (not a local HTTP server) to capture
the OAuth2 authorization code.

Expected results:

Thunderbird should intercept the redirect to https://localhost/?code=...
and extract the authorization code to complete OAuth2 authentication,
just as it does for other providers.

Fix (manually verified to resolve the issue on TB 150.0.1 / Win11):
Add the following to the "login.microsoftonline.com" provider entry
in mailnews/base/src/OAuth2Providers.sys.mjs:

redirectionEndpoint: "https://localhost",

This matches the pattern already used by other providers (e.g. Google
uses redirectionEndpoint: "https://127.0.0.1").

I am using an email account which uses an email address using outlook.office365.com as its IMAP server and which requires daily re-authentication. I can confirm that this particular issue has been affecting me since 23/04/2026.

Everything was working fine in Thunderbird 149, but when I upgraded to Thunderbird 150, the account would no longer authenticate and would no longer receive or send emails. I also have the account on another computer using Thunderbird ESR 140 and it has not been affected by this issue.

I have applied the fix detailed by the reporter to my Thunderbird 150 installation and can confirm that it does work. After editing OAuth2Providers.sys.mjs I can send and receive emails successfully from this account again.

Argh! Apologies for the trouble, I specifically tested outlook/hotmail accounts to make sure this wasn't a problem, not sure why this only happens for some accounts.

Can you tell me whether these accounts are @outlook.com or @hotmail.com, and what year they were created? If you're willing, I'd also like to know what happens if you remove the redirectionEndpoint, and set mailnews.oauth.useExternalBrowser to true in the config editor.

Flags: needinfo?(jtracey)
Assignee: nobody → jtracey
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

My account is not an @outlook.com or @hotmail.com address, but does use outlook.office365.com as its IMAP server. I believe it was created in 2016.

I have upgraded to Thunderbird 151.0 and the problem has returned (as expected). However, when I set mailnews.oauth.useExternalBrowser to true, the account was able to successfully log in and retrieve emails.

Follow-up with additional testing results:

My account is an @hotmail.com account. I believe it was created sometime in the
early 2000s, although I do not know the exact creation year. The oldest email
currently present in the mailbox is from January 2008.

The original failure happened on Thunderbird 150.0.1. At that time, manually
adding redirectionEndpoint: "https://localhost" to the Microsoft provider in
OAuth2Providers.sys.mjs allowed the account setup to complete successfully.

Later, Thunderbird was automatically updated to 151.0, which reverted my manual
omni.ja patch. I deleted and re-added the Hotmail account to check whether the
same issue still occurred on 151.0 without the manual patch.

mailnews.oauth.useExternalBrowser was false throughout.

In the existing profile, the OAuth popup did not appear and the account was added
successfully, possibly due to reuse of a cached refresh token.

I then tested with a newly created Thunderbird profile. In the fresh profile, the
OAuth popup appeared, Microsoft authentication completed successfully, the popup
closed automatically, and the account was added without error.

I also inspected OAuth2Providers.sys.mjs from Thunderbird 151.0's omni.ja and
confirmed that the proposed fix is not present there yet: the Microsoft provider
for login.microsoftonline.com still does not define redirectionEndpoint. The
redirectionEndpoint values I found belong to the test-only providers, not to the
Microsoft provider.

One possible explanation is that my Windows 11 installation is signed in with the
same personal Microsoft account, and Windows Web Account Manager / the Windows
account broker may be allowing authentication to complete using that account. If
so, my successful test may not have exercised the same localhost redirect path
that failed originally.

Therefore, I do not think my successful tests on Thunderbird 151.0 should be
interpreted as evidence that the issue is fixed in 151.0. The redirectionEndpoint
fix still appears to be absent from the Microsoft provider in Thunderbird 151.0,
and the patch may still be needed for environments that do hit the normal
localhost redirect flow.

Comment on attachment 9587999 [details]
Bug 2036505 - Revert removal of non-standard OAuth redirectionEndpoint for Microsoft. r=#thunderbird-reviewers

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set: This reverts a prior OAuth configuration change for Microsoft accounts, to switch back to an https localhost redirect target instead of http. We can't apply this to Daily because it would break the external browser OAuth flow (which also fixes this bug), so we'll need to just apply it to Beta and Release directly.
  • User impact if declined: Some unknown subset of Microsoft accounts will be unable to log in.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Daily?: No
  • Has the fix been verified in Beta?: N/A
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This one line config change reverts behavior back to what it was prior to bug 2019793. Only Microsoft users who are affected by the bug or manually flipped the external browser pref in advanced config will notice any difference (the latter will see the the old built-in flow return for Microsoft accounts).
  • Does the fix cause any migrations to be skipped?: No
  • String changes made/needed: N/A
Attachment #9587999 - Flags: approval-comm-beta?

I did everything you said, but i still encounter the problem.
Please could you provide an update ?

Target Milestone: --- → 153 Branch

Comment on attachment 9587999 [details]
Bug 2036505 - Revert removal of non-standard OAuth redirectionEndpoint for Microsoft. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta (152.0b3 scheduled for June 3)

Attachment #9587999 - Flags: approval-comm-beta? → approval-comm-beta+

(In reply to Yannick from comment #8)

I did everything you said, but i still encounter the problem.
Please could you provide an update ?

Sorry, can you clarify what you did, and what you are seeing?

Flags: needinfo?(yannick.corniquet)

Pushed by sking@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/bc34aadf1536
Revert removal of non-standard OAuth redirectionEndpoint for Microsoft. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: