MODIFY: Custom Oauth options (add-on with example, EWS advanced fields, etc

[rtanglao]

From Google Doc: [SoW] Account Hub Manual Config - UX Refinement & Oauth

• Possibly one or more of the following articles:
  • Thunderbird and Exchange
  • OAuth2 for Thunderbird
  • Account Hub for Thunderbird Desktop

[tobypilling]

Probably would be ok in here OAuth2 for Thunderbird if we don't want a new article about custom Oauth.

But we would want to link them to a specific section or make it very obvious in the TOC that they need to read about what customization options are available to them.

This content needs to describe how to create an add-on containing custom Oauth configuration then install it. It also needs to explain how an account can be created in non-functional state and then Oauth configuration added after the fact to authorize and enable the account.

[tobypilling]

Once you have the confirmed stub URL, could you please comment here to provide the link to the team:
https://bugzilla.mozilla.org/show_bug.cgi?id=2052906

Thanks!

[rtanglao]

Once you have the confirmed stub URL, could you please comment here to provide the link to the team: https://bugzilla.mozilla.org/show_bug.cgi?id=2052906

Thanks!

@toby when do you need the stub article? Week of July 13th is fine right?

[tobypilling]

Yes indeed, that would be great. Thanks!

[tobypilling]

Hey @rtanglao - can you possibly generate the stub URL today so that Kevin can finish up his patch to include the link?

[tobypilling]

We should probably describe the different ways users and administrators can configure OAuth2 in Thunderbird, depending on their requirements.

Built-in OAuth2 providers
Thunderbird includes built-in OAuth2 support for several major providers (Google, Microsoft, Yahoo, AOL, etc.). For these providers, no additional configuration is normally required.

Custom OAuth2 providers via add-ons
In Thunderbird 139, we introduced a new WebExtension API that allows add-ons to register OAuth2 providers:

Bug 1967370
https://webextension-api.thunderbird.net/en/mv3/oauthProvider.html

This makes it possible for administrators or third-party developers to package OAuth2 configuration (client ID, authorization endpoint, token endpoint, scopes, etc.) inside an add-on and deploy it to multiple users.

Several community projects already make use of this API:

https://github.com/ttaeschn/Thunderbird-OAuth2-Provider-Plugin
https://github.com/sonroyaalmerol/xoauth-thunderbird
https://github.com/raa-org/thunderbird-custom-idp

Until now, this mechanism could only register providers for hostnames that Thunderbird did not already support. Built-in providers always took precedence.

Bug 2055286 extends this so that add-ons can optionally override Thunderbird's built-in OAuth2 configuration for selected email domains. This is particularly useful for organizations using Microsoft 365 with their own Azure tenant and application registration.

The override is based on the authentication username (which must be an email-style username containing a domain). The add-on can specify one or more domains that should use its OAuth configuration while all other users continue to use Thunderbird's built-in provider.

Per-account OAuth2 customization

Separately, Thunderbird now supports manually customizing OAuth2 settings for individual accounts from the Account Settings UI.

This was initially implemented for Microsoft Exchange accounts in Bug 1984494

Work is underway to provide similar functionality for IMAP accounts in Bug 2053191

Unlike the add-on approach, this is intended for configuring individual accounts rather than deploying a configuration across many users.

Future direction: Dynamic Client Registration

We have also begun work on supporting OAuth Dynamic Client Registration in Bug 1602166

This is based on the IETF "OAuth Profile for Open Public Clients" work:

https://datatracker.ietf.org/doc/draft-ietf-mailmaint-oauth-public/

Support for this has recently been implemented in the Stalwart mail server, providing a real-world server that Thunderbird can use during development and interoperability testing.

Longer term, this should reduce (or even eliminate) the need for manually distributing client IDs or OAuth configuration for many providers, allowing Thunderbird to register itself dynamically where supported.

---

Rather than focusing on one specific feature, it may be more helpful to explain the available options:

Built-in OAuth2 support (works automatically for major providers).
Installing an add-on to provide organization-wide OAuth2 configuration.
Customizing OAuth2 settings for an individual account.
(Future) Dynamic Client Registration for servers that support the standard.

This gives users and administrators a clearer picture of which solution best fits their environment, instead of presenting the features as unrelated pieces.

[rtanglao]

Hey @rtanglao - can you possibly generate the stub URL today so that Kevin can finish up his patch to include the link?

sorry i missed this. what would be a good slug? tb-custom-oauth perhaps?

[tobypilling]

Yes, thanks! ^^ @klamping

[rtanglao]

• slug was created at: https://support.mozilla.org/kb/tb-custom-oauth @klamping @tobypilling