Thunderbird Client ID no longer works?

[bwbug]

For one of my Office 365 email accounts, I can no longer authenticate using the proxy (using the Thunderbird Client ID).

I realize that this might technically not be an issue with email-oauth2-proxy per se, but the Thunderbird Client ID is still referenced in your README, and you did indicate as recently as July 4 that the new Thunderbird client ID worked for authenticating with the proxy, so I'm hoping that you will be willing/able to provide some assistance.

When using the older Client ID for Thunderbird (08162f7c-0fd2-4200-a84a-f25a4db0b584) and the corresponding Client Secret, I now (as of Aug. 1) get the following error message:

Message: AADSTS7000112: Application '08162f7c-0fd2-4200-a84a-f25a4db0b584'(Thunderbird) is disabled.

When I changed the Client ID to 9e5f94bc-e8a4-4e73-b8be-63364c29d753 and removed the Client Secret (and also updated the oauth2_scope as specified here), I now get the following error message instead:

Message: AADSTS50011: The redirect URI 'http://localhost' specified in the request does not match the redirect URIs configured for the application '9e5f94bc-e8a4-4e73-b8be-63364c29d753'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

In both cases, the authentication ceremony appears to complete successfully (with a "Success" message in the browser) before the error message is triggered upon redirect.

Can you confirm that you are still able to use the email-oauth2-proxy with a Thunderbird Client ID to authenticate to an Office 365 or Microsoftonline account, and if so provide some assistance with troubleshooting my set-up?

Thank you!

[bwbug]

@simonrob You can close this issue. I determined based on the changes in the Thunderbird code base that in addition to updating the Client ID, I had to change the value of redirect_uri from http://localhost to https://localhost.

Perhaps you might consider updating the README.md to link the new OAuth2Providers.sys.mjs file in the Thunderbird repo instead of the deprecated OAuth2Providers.jsm file.

As a final comment, I noticed that the changes to oauth2_scope that you recommended here have been implemented in the template emailproxy.config entry for [your.email@outlook.com], but not in the entry for [your.office365.address@example.com]. Is this intentional?

The email account in question is of the former variety ("your.office365.address@example.com"), so I'm wondering if I should change the oauth2_scope URLs back to using the office365.com domain.

Thank you.

[simonrob]

Thanks for the pointer to the new Thunderbird file – I'll link to this.

Re: the two different configuration file examples – I've kept both of these here because for me, both Thunderbird IDs still work. Perhaps an administrator on your side has disabled the older ID?

[bwbug]

I've kept both of these here because for me, both Thunderbird IDs still work.

So the office365.com domain in the scope should be used when using the old Thunderbird ID, and the office.com domain when using the new ID? Can this rule be generalized to other Client IDs? I'm a bit confused how the configuration of oauth2_scope should be done based on Client ID (other than trial and error).

To add an observation, the older client ID (and the old scope variable using the office365.com domain) does still work on one of my O365 mailboxes but not on the other (the mailboxes are hosted on different tenants). I had assumed that this might have in part been due to the possibility that the cached access token was still being accepted by the second tenant instead of going through the full OAuth2 authorization process. My problems started when the first tenant required me to re-authorize.

Possibly also relevant: Thunderbird 129 was released on 1 Aug 2024, which coincides with the date that I first encountered this "Thunderbird is disabled" error. I do not have a good understanding of how Mozilla does releases, but if I understood their release schedule correctly, then the 1 Aug 2024 release would have been the first standard release that used the new Client ID (while it was previously also used in the Thunderbird Extended Support Release 102, released 12 Sep 2023).

If the use of cached access token does not explain the discrepancy between tenants, then you may be right that a fastidious admin marked the old Client ID as disabled (and deauthorized tokens created using the old ID), as soon as Thunderbird 129 was released.

[simonrob]

The honest answer is that many of the values in the configuration file have been discovered through trial and error, support requests or following other clients' examples, because historically documentation has been quite lacking.

The scope values in the Microsoft documentation were last updated in 2020, but Thunderbird only updated to match these in 2022. Microsoft's documentation still uses the office365.com versions in examples elsewhere, and O365 also requires this in certain configurations (e.g., the .default scope that is used for CCG, etc).

Since the newer scope values work with both the old and new Thunderbird IDs, I think it's relatively safe to presume they are treated as aliases for each other. The additional example here was only added recently to cover a case where the older scopes didn't work, so I'll go ahead and remove the old ones to lessen the confusion.

[bwbug]

Thank you for the further explanation. If the permitted scope is defined by the client owner (Mozilla) in their Entra admin account, then perhaps it is important for the oauth2_scope variable to match what the client admin has asserted to Microsoft. And since the first appearance of the new client ID in the Thunderbird codebase was contemporaneous with the change in base domain for the scope URLs, perhaps it is not far-fetched to assume that the older scope domain (office365.com) must be used with the original Thunderbird Client ID, while the newer scope domain (office.com) must be used with the current Thunderbird Client ID. I have not tested this hypothesis.

If I can make one suggestion, it would be to consider adding some pointers to the emailproxy.config documentation (perhaps under Office 365 customisation) to suggest trying office365.com in the oauth2_scope parameter (if the office.com domain does not work), and trying https://localhost in the redirect_uri parameter (if http://localhost does not work).

[simonrob]

I did check both Thunderbird IDs, and they work fine with the new scopes, which is why I've switched this over. The example configuration file is meant to show the setup required, but reuse of other clients' secrets is a bit of a grey area, so I tend to stick to the officially documented values unless lots of issues are being caused.

The file does already discuss the redirect_uri value and the need for it to match what is specified in the OAuth 2.0 client configuration. Fortunately, the error messages from most providers are pretty helpful here, and normally tell you what the correct value needs to be.

Thanks again for pointing this out – glad you were able to figure out the root cause.