1591782 - Modify the user interface to allow the user to select an oAuth secret provider and make oAuth available based on that preference being set.

Status: NEW

(MailNews Core :: Account Manager, enhancement)

Description

[Matt]

Currently Thunderbird offers oAuth as a sign in option for selected providers. Given the proliferation of yahoo in particular as a contracted email provider in the ISP space, it makes sense for the yahoo secret to be made available to users not only of yahoo email addresses, but also BT, ATT and a number of others. It would also be a benefit when the provider changes the server name to be used.

What I suggest is an additional drop down in the accounts setting above authorisation method that allows the user to specify an oAuth provider to use that makes oAuth available to be selected in the authentication method. That way server names not directly linked to the setting we currently provide can be used, for example inbound.att.new, or if one of the providers reinvents themselves again like Hotmail/msn/live/oulook has done every few years a software change will not be required to accommodate a wholesale change of server names.

Comment 1

[Jorg K (CEST = GMT+2)]

Something the product manager should take note of.

Comment 2

[Magnus Melin [:mkmelin]]

xref bug 505267 and maybe dupe of bug 1494219

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #2)

xref bug 505267 and maybe dupe of bug 1494219

Matt?

Comment 4

[Matt]

Probably a dup, but we need to expand the scope to basically any and all providers. Such as the frontier user in bug 1593594 or the myriad of ATT customers and Verizon customers that are having issues because of changes at Yahoo. There are a few accidental ones like gsuite, but we need to put to user in a position to apply manual settings as they can with everything else in account settings. This is something I have seen done in the android world when manually configuring mail accounts, letting the user decide. Even if it does give them the power to mess things up, we already have them choosing encrypted passwords for accounts that do not support it.

I will leave it to you to decide which way to dup this.

Comment 5

[Orion Poplawski]

See also bug 1699487

Comment 6

[Wayne Mery (:wsmwk)]

How does this relate to, or differ from, bug 1602166?

Comment 7

[Matt]

The other implements the dynamic protocol. This is letting the user choose which OAuth provider will authenticate them on this account..

Bug 1602166 is fundamentally just as is used in Bugzilla. The Bugzilla folk "trust" OAuth tokens from other providers. I am not even all that sure if any mail providers offer it from their end or how it is configured, but with an ongoing increase in interest with OAuth generally. The protocol can be used to query the server as to what OAuth tokens it will honour. From the RFC;

In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0
authorization server, the client needs specific information to
interact with the server, including an OAuth 2.0 client identifier to
use at that server. This specification describes how an OAuth 2.0
client can be dynamically registered with an authorization server to
obtain this information."

This is to allow the users, on say the following ATT domains but not restricted to just those, with mail provider to just specify from Thunderbird list of registered providers on to use. It would also allow the correct usage of OAuth in the autoconfig process where the domain is not specifically OAuth registered but known to belong to the same provider. There is no way currently for known ATT domains to be set to use yahoo OAuth for instance. We trust our users to enter all the other settings, and mess them up. Why not allow them to choose who they think authorises or ultimately provides their service.

@ameritech.net
@att.net
@bellsouth.net
@currently.com
@flash.net
@nvbell.net
@pacbell.net
@prodigy.net
@sbcglobal.net
@snet.net
@swbell.net
@wans.net