2055286 - Extend add-on API for OAuth client registration to allow override

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, enhancement, P3)

Description

[Toby Pilling [:tobyp]]

The current oauth_provider WebExtension API is useful for registering OAuth providers for hostnames that Thunderbird does not already know about. However, it cannot currently be used to customize OAuth configuration for providers that already have built-in registrations, such as Microsoft 365, because registration fails if the hostname already exists.

This makes it difficult for organizations that use tenant-specific Azure application registrations to deploy a managed OAuth configuration via an XPI.

The initial implementation should allow extension-provided hostname registrations to take precedence over built-in hostname registrations while the extension is active, restoring the built-in configuration when the extension is unloaded.

We should also allow registrations to be restricted to particular email domains using an optional domains manifest property, so that built-in and extension providers can coexist for different accounts using the same hosted service.

Comment 1

[Toby Pilling [:tobyp]]

Attachment: Bug 2055286 - Allow extension OAuth providers to override built-in hostname registrations. r=#thunderbird-reviewers

Comment 2

[Toby Pilling [:tobyp]]

After thinking this through a bit more, I think emailDomains (previously domains) is most useful for choosing the right OAuth provider when more than one registration applies to the same service hostname, rather than as a security feature.

The lookup order would be:

an extension provider matching both the hostname and email domain
an unrestricted extension provider matching the hostname
Thunderbird’s built-in provider for that hostname

This would allow, for example, two organizations using the same Microsoft 365 hostnames to provide different tenant-specific OAuth configurations, while still preserving the existing use case where an add-on supports a provider but cannot know every customer domain in advance.

Internally, a provider that declares multiple hostnames and email domains would create one registration for each combination, such as:

office365.com|foo.com
office365.com|bar.org
outlook.com|foo.com
outlook.com|bar.org

Registration should validate the complete set before adding anything. If an issuer or hostname/domain combination is already registered, the whole registration should fail and leave the existing provider maps unchanged. We should also retain the extension ID with the provider details so that a follow-up UI change can show which extension supplied the effective OAuth configuration.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/486d3bc1ba25
Allow extension OAuth providers to override built-in hostname registrations. r=edicharry,aleca,darktrojan

Comment 4

[Toby Pilling [:tobyp]]

Release Note Request (optional, but appreciated)
[Why is this notable]:
Users and organizations can now use OAuth provider add-ons to override Thunderbird's built-in OAuth2 configuration for specific email domains or hostnames. This makes it easier to deploy organization-specific OAuth2 settings (such as Microsoft 365 tenants with their own Azure application registration) without affecting other users. Thunderbird also now identifies when OAuth2 settings are being provided by an extension in Account Settings.

[Suggested wording]:
OAuth provider add-ons can now override Thunderbird's built-in OAuth2 configuration for selected email domains or hostnames, making it easier for organizations to deploy custom OAuth2 settings. Thunderbird also displays when an account's OAuth2 settings are being provided by an extension.

[Links (documentation, blog post, etc)]:
WebExtension OAuth Provider API: https://webextension-api.thunderbird.net/en/mv3/oauthProvider.html
Knowledge Base: https://support.mozilla.org/kb/tb-custom-oauth