Cannot customise OAuth2 client ID for OAuth2 providers
Categories
(MailNews Core :: Backend, enhancement)
Tracking
(Not tracked)
People
(Reporter: arcayr, Unassigned)
References
Details
Steps to reproduce:
- Opened Thunderbird to configure a new email account running inside Office 365 with modern authentication
- Configured the account to use OAuth2
Actual results:
The OAuth2 login was denied due to an unapproved application ID.
Expected results:
Ideally there's a way to customise this application ID and secret for the user, if they so require. In some large enterprises once an application ID is created, that's it.
Evolution supports this functionality[1] which has been useful in the past by way of a simple input box for each when the OAuth2 is selected. For Thunderbird, given the single hard-coded entry, perhaps a checkbox for "use custom client ID" as well.
While I am capable of modding the OAuth2Providers.jsm file myself to "hard-code" the value I need to use, I'm unfortunately nowhere near experienced enough with the UI framework of Thunderbird to submit a full patch.
1: https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2#Configure_the_account_in_Evolution
|
||
Comment 1•3 years ago
•
|
||
We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).
Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.
In general, requesting to be able to customize this is reasonable but I can't say when we'll want to implement this functionality. It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications.
"What client ID do you have set?" is not a question I want to be asking people in bug reports... ever really. You also have to use very specific settings for stuff to work properly, and we are absolutely 100% NOT providing free support on "how do I set up my own client ID?". Never going to happen.
Having struggled with Microsoft's systems and policies with oAuth for several months, they're incredibly complicated and the documentation is borderline useless in many cases. So I would caution anyone who wants to opt into maintaining this themselves...
|
Reporter | |
Comment 2•3 years ago
|
||
We intentionally changed the client ID so enterprises are going to have to approve the new one, or not use Thunderbird, really. They're never going to be able to use the old one again, and it could be completely removed at any time(probably not until 102 goes out of support, though).
Given the way these client IDs/oAuth registrations work, there's going to be some turnover over time since it's not easily possible to transfer them between entities. There's even cases where you might have to create a new application ID to make certain changes.
Actually, we never had the old client ID in there either. A custom one was made for reasons that are not my department.
It also encourages people to change the client ID, which is not something I'm sure we actually want them doing. Because it limits our ability to control the auth registration and is almost certain to cause additional bug reports and support burden as Microsoft change their policies and enterprises don't properly update their applications.
"What client ID do you have set?" is not a question I want to be asking people in bug reports... ever really. You also have to use very specific settings for stuff to work properly, and we are absolutely 100% NOT providing free support on "how do I set up my own client ID?". Never going to happen.
Ideally yeah, the vast majority of users are just using the ID provided for them. Given there's my case, though, I'd imagine there's a small handful of people who really like Thunderbird but are being locked out by this unless they patch the source code. I just really would prefer it to be at least an about:config setting or something - empty if the default is to be used, otherwise it uses the ID provided. Consider it an "enterprise anomaly" setting.
|
|
Reporter | |
Comment 3•3 years ago
|
||
I just realised I should probably clarify here. Previously, I was using a patched version of Owl by Beonex that did similar to here - used the application ID that we use internally to authenticate. This didn't suddenly stop working but has in fact never worked for me in "vanilla" Thunderbird.
I was highly interested by the addition of M365 OAuth2 to Thunderbird but disappointed to see I couldn't set the application ID without patching the source code, effectively meaning I would still need to use the extension instead of the core feature. This isn't a bug where I was using it and now it doesn't work, but instead a feature request so I can actually start using it in the first place.
|
|
||
Comment 4•3 years ago
|
||
(In reply to Elliot Speck [:arcayr] from comment #3)
I was highly interested by the addition of M365 OAuth2 to Thunderbird but disappointed to see I couldn't set the application ID without patching the source code, effectively meaning I would still need to use the extension instead of the core feature. This isn't a bug where I was using it and now it doesn't work, but instead a feature request so I can actually start using it in the first place.
Thanks for the clarification. I thought this was related to some of the other oAuth issues we've been having. I do think it'd be reasonable to allow this as long as it came with a caveat that we don't support it and if you change it we can't help you with any resulting oAuth issues you might have.
|
||
Comment 5•3 years ago
|
||
This is obviously to do with standards compliance and giving control to IT departments and administrators of the O365 accounts.
Unfortunately, this is at the expense of users. Ultimately, with this change thunderbird on its own is unusable for me so thunderbird (an application I like a lot) will loose users because they can't use it to connect to their work email account unless admins enable TB's new clientId.
I have started using davmail as a workaround, which does let you specify the clientid but it is rather frustrating that thunderbird fully supports everything I want to do but is blocked by not being able to override the oauth2 client ID.
I am not expecting this functionality to have an associated gui setting or be easily accessible, just being able to set it in about:config would be a reasonable.
|
|
Reporter | |
Comment 6•3 years ago
|
||
After some thought about it I'd also be happy with it just in about:config versus being a GUI option. This would keep it appropriately hidden from people who may accidentally break their configuration, but provide power to users like myself and Tom.
Generic proposal to solve this for all email providers with OAuth / OpenID.
Add generic Oauth2 / OpenID connect option
https://bugzilla.mozilla.org/show_bug.cgi?id=1866093
|
||
Comment 8•8 months ago
|
||
I did some work here: https://phabricator.services.mozilla.com/D231454
and would appreciate any feedback
Description
•