Closed Bug 1685414 Opened 3 years ago Closed 2 years ago

Office365 OAuth2 Implementation uses Confidential Client instead of Public Client access

Categories

(Thunderbird :: Security, defect, P1)

Product:
Thunderbird
Component:
Security
Type:
defect

Tracking

(thunderbird_esr102+ fixed, thunderbird107 fixed)

Status:
RESOLVED FIXED
Milestone:
108 Branch
Tracking Flags:
Tracking Status
thunderbird_esr102 + fixed
thunderbird107 --- fixed

People

(Reporter: emailthereeves+bugzilla, Assigned: leftmostcat)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
wsmwk
: approval-comm-esr102+
Details | Review
bug1685414_old_o365_oauth2_settings.patch
2.30 KB, patch
Details | Diff | Splinter Review
screenshot of MS admin approval page
45.21 KB, image/png
Details

Thunderbird using Office365/OAuth2 will not observe Microsoft Azure Conditional Access policies, and therefore survive off-network connections as well as password changes. I spent several months troubleshooting with Microsoft. What came out of our joint investigations is summarized below:

The Thunderbird Azure App which is used in the implementation of Thunderbirds Office365 OAuth2 authentication uses a confidential client configuration that is designed for protected services/daemons which are usually on protected platforms that can reasonably be expected to protect secrets. Thunderbird is a desktop application that cannot reasonably be expected to protect secrets, and therefore Microsoft has advised that the Azure App should be reconfigured as a public client, and not use client secrets.

The current implementation requires Thunderbird to have its Azure App Client Secret hard coded into the source which anyone has access to. A malicious application can impersonate Thunderbird by using this client secret.

I'm recommending an expedient review of this bug for the sake of security. I'm marking this to keep it hidden so that others will not immediately go perusing the source code looking for the client secret.

iirc this is previously reported

Flags: needinfo?(mkmelin+mozilla)

(In reply to Wayne Mery (:wsmwk) from comment #1)

iirc this is previously reported

Hi Wayne, I reported it shortly after the enhancement bugfix was closed bug 1528136 comment 173. You replied to one of my other comments a few comments later so You might have read about it there. While there was response from dev after comment c173, nothing was said about it. I revived the convo 2 weeks ago after Microsoft and I come to some conclusions... others chimed in but still nothing from dev. So I figured Id issue an actual bug defect for it. If it’s been reported by someone elsewhere also, I have not come across it in my travels. :)

Thanks!
Jeremy

IIUC:
You connect.
Then you change authentication credentials on the server.
You expect Thunderbird to automatically get disconnected after a while, because the credentials that Thunderbird had used at connection time are no longer valid.
You observe that TB remains connected.

You claim that TB was registered with the MS using a mechanism that prevents the automatic disconnect.

You suggest that TB should communicate with MS and get the app registration changed.

Can you say if such action would have any other side effects?

Is this really an issue on the TB client side? It seems to me that the server should be smarter and match logged in sessions and disconnect accordingly?

This seems to be a configuration issue on the MS side, not a software issue on the TB side. So I'm not convinced it should be tracked on the TB side.

Apparently the MS service needs better cooperation from clients to behave securely. It would be good if someone could provide clear steps on how to change the TB configuration to achieve that cooperating behavior, and what the potential (negative) consequences for TB could be.

Also, you have effectively described the issue in bug 1528136, so I'm not sure why this here needs to remain security sensitive.

I'm not sure what severity this should be given on the Thunderbird side. Maybe N/A because it isn't related to Thunderbird's software?

I understood that the client certificate is currently marked at Microsoft as "confidential", whereas it should be marked "public", given that is, in fact, public. I understood that the setting is currently wrong.

@Jeremy Reeves: If you want TB devs to give this bug priority, it helps to:
show what the actual risk and danger is right now. What difference does it make, concretely, to change this setting? What harm can be done in the current situation which would be prevented when the setting was changed?

Flags: needinfo?(emailthereeves+bugzilla)

  1. Client ID and Client Secret is embedded in the code. That pair can be used in malware for users to authenticate what they perceive to be Thunderbird, but is not. Once malware is authenticated using the Thunderbird app, it can exfiltrate mailbox content.

  2. Organizations implement security controls with O365 Conditional Access policies. Our organization use Network location as one of the conditions. Since Thunderbird is granted a refresh token with confidential client access, that refresh token bypasses Conditional Access policies. Therefore, once a token is issued, that client can access the users mailbox from any network location.

  3. It survives a password reset and remains authenticated to the users account unless the users session tokens are revoked by an administrator.

Changing the AzureAD app to a Public client should result in Thunderbird observing Organizational policies, expiring tokens when passwords are reset. Making the change from Confidential Client to Public client may require changes to code to handle the new authentication flow.

In order to change from confidential client to public client, I suspect it would require a new AzureAD app to be created (because backwards compatibility with all the clients currently deployed using the confidential client flow would break if they just change the existing AzureAD app) and new code to support the new AppID and authentication flow.

Flags: needinfo?(emailthereeves+bugzilla)
Version: unspecified → 78

Microsoft announced the retirement of Basic Auth for IMAP again for Oct 2022.

I realize having published this “security” and it being hidden was probably not wise to get visibility from the community. Can it be changed to public so it can be seen publicly?

Is this being looked at in any capacity? I’m preparing to notify our IT Security Working group that their users will no longer be eligible to use this product after Oct 2022 if the issue hasn’t been resolved by then, and I am dreading that conversation. Many of them are Linux users who find TB to be their best option. Help me help them!

@Jeremy: I concur. There's a checkbox "Security-Sensitive Mail bug" at the top of this bugzilla page, under heading "Security", which is collapsed by default. Try to uncheck that checkbox (not the other checkboxen there!). I tried, and I don't have the ability to uncheck it.

(In reply to Ben Bucksch (:BenB) from comment #8)

@Jeremy: I concur. There's a checkbox "Security-Sensitive Mail bug" at the top of this bugzilla page, under heading "Security", which is collapsed by default. Try to uncheck that checkbox (not the other checkboxen there!). I tried, and I don't have the ability to uncheck it.

I cannot uncheck either.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Group: mail-core-security

It appears Jeremy Reeves has communicated clear reasons why "confidential" client needs to be changed to "public."   Our organization has banned Thunderbird from using OAuth2 because of the issues. Since Microsoft will block PLAIN auth (username/password) logins on Oct 1, Thunderbird will be unusable to us. It would be really nice to have this issue corrected before that time. We appreciate the time and effort on correcting this. If there is anything we can do to assist, please let us know. Thank you!

Does this stand any chance of being fixed in the next 2.5 months?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(mkmelin+mozilla)

So after looking into this some, we need to be using the authorization code flow(maybe with PKCE): https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

That flow does not use a client secret, only a client ID. There's a Microsoft-published JS library that implements it. I don't know what library we're currently using for this if anything.

On the "Authentication" tab of the Azure app registration, there is a checkbox for "Allow public client flows" as well.

And I think you need to add a "Mobile and desktop applications" platform configuration.

Andrei, see comment 5. This is mostly a configuration change, not really a code change.

I don't know what library we're currently using for this if anything.

As you suspected, Mozilla has its own implementation of OAuth2, which we use.

(In reply to Ben Bucksch (:BenB) from comment #13)

Andrei, see comment 5. This is mostly a configuration change, not so much a code change.

I don't know what library we're currently using for this if anything.

As you suspected, Mozilla has its own implementation of OAuth2, which we use.

I don't have any visibility into the current configuration, unfortunately. Perhaps it is just a matter of changing the platform type and checking the public client checkbox. I did look at the code and it appears we currently use a client secret though, which we definitely should not be using.

we currently use a client secret

We do that for all OAuth2 providers. But we can tell the provider that this client will be public and that they shouldn't trust it. That's what this bug is about: We're currently incorrectly telling Microsoft that the secret is confidental and remains on our servers only. We should be telling Microsoft that this secret is part of an application that ships to end users. They have a specific flag for that. This bug is about setting that flag. That's all.

I don't have any visibility into the current configuration, unfortunately.

Yes, whoever wants to fix this bug needs access to the Microsoft account (i.e. needs to know the password to that account) which we used to create the client ID, and change the configuation of that client ID.

OK, after some further investigation with Magnus:

  1. The existing configuration has Thunderbird set to use the "Web" platform category which probably is why this is being treated as a confidential client. It should be using the "Mobile and Desktop Applications" platform category.

  2. Unfortunately, the way this is configured, you can't add two platforms with the same redirect URI. That means we must delete the old one before we can change it. This will cause an interruption in clients being able to login.

Therefore, we need to be really really certain that the new configuration will work properly BEFORE we implement it. So, we will have to test the correct configuration on a different client ID maybe with a Try build, confirm that it resolves this bug, and then we can change the live configuration. Quickly.

Regarding the client secret, we're not using the PKCE flow so we still need that. We probably should eventually, as Microsoft already requires it for single page apps. Since it's the default in their library now for all native applications, I bet they'll require it at some point.

Flags: needinfo?(mkmelin+mozilla)

We're already using the authorization code flow, which is the blessed alternative. So I don't think that needs any changes.
It should be only the configuration change, but... like Andrei describes, that "only" is unfortunately fairly involved :(

Is this related to bug 1697805?

See Also: → 1780083
See Also: → 1697805, 1780765

OK, so here's that needs to happen for us to make progress on this bug. This is going to be complicated, I apologize in advance, but Microsoft's oAuth system and developer website is completely and totally insane to an absurd degree.

a) We need some way to check if a client is "confidential client" or "public client". I don't know if this is in the docs, I couldn't find it if so. This is so we can confirm any change we make resolves the issue.

b) We need to change the application type in Azure, and hopefully that will fix #1. To do this, you have to add a new Platform configuration under Authentication in the application's management profile in Azure.

c) Unfortunately, you cannot have two platform types with the same redirect URI. That means to change the live configuration, we would have to delete the old (web) platform and add a new (desktop) platform. This will probably break login for at least a few seconds, and may break existing login tokens. We need to determine if that will happen.

Therefore, we must:

  1. Add a "Web" platform to our test app.
  2. Change the code to use the authentication client/secret in our test app and do a build.
  3. Check if login works as expected, leave session logged in.
  4. Delete the 'web' platform type and add a 'desktop' platform type, with the same redirect URI.
  5. Check if the logged in session still works. If not, log back in again.
  6. Run <some test; see a)> to determine if this actually makes Thunderbird appear as a Public Client. Worst case, a try build that people in this bug can try.

The two important pieces of information we need are:
X) What happens when you delete a platform and create a new one? Does it break existing login sessions? Does login start working again immediately, or is there any kind of delay?
Y) Does changing the platform type from "Web" to "Mobile and desktop applications" change Thunderbird to a "Public Client"?
Y-a) If it doesn't fix the client type, how do we fix it? Is PKCE required to be correctly categorized? (hopefully not)

@mkmelin: Our current redirect URI is just "http://localhost" right?

Assignee: nobody → leftmostcat
Status: NEW → ASSIGNED

(In reply to Andrei Hajdukewycz [:sancus] from comment #19)

OK, so here's that needs to happen for us to make progress on this bug. This is going to be complicated, I apologize in advance, but Microsoft's oAuth system and developer website is completely and totally insane to an absurd degree.

a) We need some way to check if a client is "confidential client" or "public client". I don't know if this is in the docs, I couldn't find it if so. This is so we can confirm any change we make resolves the issue.

b) We need to change the application type in Azure, and hopefully that will fix #1. To do this, you have to add a new Platform configuration under Authentication in the application's management profile in Azure.

c) Unfortunately, you cannot have two platform types with the same redirect URI. That means to change the live configuration, we would have to delete the old (web) platform and add a new (desktop) platform. This will probably break login for at least a few seconds, and may break existing login tokens. We need to determine if that will happen.

Therefore, we must:

  1. Add a "Web" platform to our test app.
  2. Change the code to use the authentication client/secret in our test app and do a build.
  3. Check if login works as expected, leave session logged in.
  4. Delete the 'web' platform type and add a 'desktop' platform type, with the same redirect URI.
  5. Check if the logged in session still works. If not, log back in again.
  6. Run <some test; see a)> to determine if this actually makes Thunderbird appear as a Public Client. Worst case, a try build that people in this bug can try.

The two important pieces of information we need are:
X) What happens when you delete a platform and create a new one? Does it break existing login sessions? Does login start working again immediately, or is there any kind of delay?
Y) Does changing the platform type from "Web" to "Mobile and desktop applications" change Thunderbird to a "Public Client"?
Y-a) If it doesn't fix the client type, how do we fix it? Is PKCE required to be correctly categorized? (hopefully not)

@mkmelin: Our current redirect URI is just "http://localhost" right?

To help get answers to your questions without impact to production, you could create a new Azure AD app replicating the current App config exactly, configure a test TB build using the new client ID and secret. Authenticate. Make the proposed changes in the new Azure AD app to observe what happens in the various circumstances you would like to have answers to. No impact to production. Changes to the Azure AD apps are usually felt fairly quick, within minutes in most cases.

I would try this out myself but I cannot get the TB source code to download anymore. A couple years ago I had it and worked fine, but I’ve tried probably 10 times over the last couple months and it keeps failing. It would seem like the server is timing out but it happens sometimes after 10 minutes and other times after an hour. No specific point in the process either. Ideas?

(In reply to Andrei Hajdukewycz [:sancus] from comment #19)

@mkmelin: Our current redirect URI is just "http://localhost" right?

Correct.

Severity: -- → S2
Priority: -- → P1

Broader query than I had posted in Matrix https://mzl.la/3F4i07M

Is there anything else we should fix in the near term? Bug 1668834?

See Also: → 1668834
Keywords: checkin-needed-tb

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

[Approval Request Comment]
User impact if declined: authentication issues for Microsoft users, eventual loss of ability to log in
Testing completed (on c-c, etc.): smoketest of Google and MS OAuth, testing needed for other providers (build available at https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=84702d076b2e53e6b3585ad7d48129d0ffd0aa9c)
Risk to taking this patch (and alternatives if risky): potential impact to OAuth2 authentication; patch could be narrowed for 102 to mitigate the chances of this if deemed preferable

Attachment #9297140 - Flags: approval-comm-esr102?

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

Lets let this live on nightly for a bit before we go to Beta. We still need to get confirmation from the bug filers that it's fixed.

Once we have that, we can go to Beta for a week or so and then roll out to ESR after that.

Attachment #9297140 - Flags: approval-comm-esr102?
status-thunderbird107: --- → affected
status-thunderbird_esr102: --- → affected
tracking-thunderbird_esr102: --- → +
Target Milestone: --- → 108 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/8a2ef67503df
switch Thunderbird OAuth2 to desktop client auth. r=darktrojan,sancus

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

I've confirmed the nightly build which contains Client ID 9e5f94bc-e8a4-4e73-b8be-63364c29d753 now correctly observes the Conditional Access policies that drove this bug. Thanks so much team.

Questions: And maybe I need to address this in a new post, but why am I prompted username/password when my namehint is already in the OAuth2 URL? Is it possible to suppress the credential prompt when a namehint is discovered? Since we have ADFS/SSO, I can enter username: a password: (blank) and it'll still discover the correct account and sign me in. So the TB credential prompt before OAuth isn't particularly necessary in all cases, is it?

(In reply to Jeremy Reeves from comment #29)

I've confirmed the nightly build which contains Client ID 9e5f94bc-e8a4-4e73-b8be-63364c29d753 now correctly observes the Conditional Access policies that drove this bug. Thanks so much team.

Thanks for verifying this!

Questions: And maybe I need to address this in a new post, but why am I prompted username/password when my namehint is already in the OAuth2 URL? Is it possible to suppress the credential prompt when a namehint is discovered? Since we have ADFS/SSO, I can enter username: a password: (blank) and it'll still discover the correct account and sign me in. So the TB credential prompt before OAuth isn't particularly necessary in all cases, is it?

To clarify, are you saying that you're entering your username in the "Email address" field in Thunderbird, but it's not filled in when the sign in window from Microsoft shows up?

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

[Approval Request Comment]
User impact if declined:
Users using Microsoft business email services may not be able to login due to deprecation of basic auth for Exchange Online on Oct 1, 2022.

Testing completed (on c-c, etc.): comm-central

Risk to taking this patch (and alternatives if risky):
This will cause anyone with oAuth logins to have to log in again, but that will have to happen at some point. This could also potentially cause login issues, but there are already login issues happening.

Attachment #9297140 - Flags: approval-comm-beta?

(In reply to Sean Burke [:leftmostcat] from comment #30)

Questions: And maybe I need to address this in a new post, but why am I prompted username/password when my namehint is already in the OAuth2 URL? Is it possible to suppress the credential prompt when a namehint is discovered? Since we have ADFS/SSO, I can enter username: a password: (blank) and it'll still discover the correct account and sign me in. So the TB credential prompt before OAuth isn't particularly necessary in all cases, is it?

To clarify, are you saying that you're entering your username in the "Email address" field in Thunderbird, but it's not filled in when the sign in window from Microsoft shows up?

Not quite. In TB I enter the User Name in the account settings. I initiate auth. The login.microsoftonline.com… auth window appears prompting a TB “Authentication Required” windows. “This site is asking you to sign in.” I enter “QWERTY” in the Username field and leave password blank. Press Ok. Immediately redirected to my ADFS IdP, which contains a username hint in the URL containing the User Name from the account settings. If successfully matched to the UPN of the logged on account and it’s authorized, it redirects back to login.microsoftonline.com to complete the auth and issue TB a token. I am not asked to enter anything into the Microsoft portal, just a basic form prompt from TB.

I further tested with a cloud-only account and there I was prompted to credential through the Microsoft form and did not see the TB credential form. So there is something there that when my identity is on-prem, TB is prompting. I would think it would instead allow the IdP to prompt if it was required to provide a credential rather than TB proxying that.

Let me know if you need any further info to understand this better.

That User Name is added as a namehint in the

Since our tenant is federated to our ADFS instance, it can single-sign on using that resource. The works because when TB opens the Oauth2 window, the namehint is already included in the URL. (This might be gotten due to a previous login, and Microsoft is able to use that). Azure AD sees the namehint (my UPN) in the URL and automatically redirects to the identity provider, ADFS, redirects back to Azure AD and In authenticated. The username/password prompt that TB presents does nothing in this scenario. As mentioned I can type anything I want in the username field, it will always defer to my domain account.

(In reply to Jeremy Reeves from comment #32)

Not quite. In TB I enter the User Name in the account settings. I initiate auth. The login.microsoftonline.com… auth window appears prompting a TB “Authentication Required” windows. “This site is asking you to sign in.” I enter “QWERTY” in the Username field and leave password blank. Press Ok. Immediately redirected to my ADFS IdP, which contains a username hint in the URL containing the User Name from the account settings. If successfully matched to the UPN of the logged on account and it’s authorized, it redirects back to login.microsoftonline.com to complete the auth and issue TB a token. I am not asked to enter anything into the Microsoft portal, just a basic form prompt from TB.

I further tested with a cloud-only account and there I was prompted to credential through the Microsoft form and did not see the TB credential form. So there is something there that when my identity is on-prem, TB is prompting. I would think it would instead allow the IdP to prompt if it was required to provide a credential rather than TB proxying that.

Let me know if you need any further info to understand this better.

That User Name is added as a namehint in the

Since our tenant is federated to our ADFS instance, it can single-sign on using that resource. The works because when TB opens the Oauth2 window, the namehint is already included in the URL. (This might be gotten due to a previous login, and Microsoft is able to use that). Azure AD sees the namehint (my UPN) in the URL and automatically redirects to the identity provider, ADFS, redirects back to Azure AD and In authenticated. The username/password prompt that TB presents does nothing in this scenario. As mentioned I can type anything I want in the username field, it will always defer to my domain account.

Thank you for the clarification. I don't have a simple answer for this, so it'd be best as a separate report.

Thanks. Will do.

That User Name is added as a namehint in the

Since our tenant is federated to our ADFS instance, it can single-sign on using that resource. The works because when TB opens the Oauth2 window, the namehint is already included in the URL. (This might be gotten due to a previous login, and Microsoft is able to use that). Azure AD sees the namehint (my UPN) in the URL and automatically redirects to the identity provider, ADFS, redirects back to Azure AD and In authenticated. The username/password prompt that TB presents does nothing in this scenario. As mentioned I can type anything I want in the username field, it will always defer to my domain account.

All this was supposed to be deleted before I posted. I originally typed and reworded that after further testing. Oops. :). Disregard that whole block.

One issue I came across: for a hosted o365 account I now get the "need admin approval" screen, so before an admin of the org has approved the new app, there's no way to log in.

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

One issue I came across: for a hosted o365 account I now get the "need admin approval" screen, so before an admin of the org has approved the new app, there's no way to log in.

I'd guess that's not a bug?

No, though it's something many, probably a large percentage of users, will come across when updating.
Until the users admin gets around to allowing it, they are locked out. I'm not sure if there's an easy way to fall back to the original app id in this case.

Maybe run another test with the new app. Add a Client Secret to it and in to the code. See if it will still works the new way with a client secret attached, as if it were the old app changed to Public client. If it does still work the new way, maybe it could be possible to change the existing Azure AD app to public client rather than pushing a new app into production? Of course users with old TB versions would experience the change, but that would be a welcomed benefit for security. And solve the tenant approval issue.

Alternatively, other apps allow overriding the default client id in config settings, such as Evolution on Linux. I know TB doesn’t currently allow for this in its config, but could it? Should it?

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

[Triage Comment]
Approved for beta

Attachment #9297140 - Flags: approval-comm-beta? → approval-comm-beta+

(In reply to Jeremy Reeves from comment #38)
I did some testing.

  • The old app can't request the new scopes (without changes)
  • Reverting scopes to original didn't change anything: still requires admin approval.

I don't think we can risk changing the old client (if it's even possible).

Old settings, in case someone needs to test something with those.

Blocks: 1798875
Regressions: 1799055
Duplicate of this bug: 1799259

Any idea when this will move to public release?

I’m aware this change will result in some issues for those users whose tenant admins require approval of the new app. Those users who don’t use beta will not know in advance to ask their tenant admins to prepare for the change, without some mechanism to notify them.

Maybe build in a temporary regression setting, where changing that setting can revert to the old client id/code until some version in the future to give non-beta users their first major warning shot. Or just go with the change and force users to take immediate action?

What’s the plan so far? Has there been much negative/positive feedback in beta?

The next scheduled release is 102.7.0 on Jan 17, there may be a minor release earlier than that but not until after Jan 3rd.

We have an issue right now where the publisher display name is "Mzla Technologies Corporation" and that's not what admins may expect(we already get questions about this from beta users). So I wanted to get it changed to "Mozilla Thunderbird" before release. However, it's increasingly seeming like that may not be possible without re-registering the application again, which I don't want to do.

And Microsoft is incredibly unhelpful on this topic, they haven't replied in over a month on my support request. This whole thing has honestly been the single worst, most byzantine, nonsensical, actively hostile to developers oAuth registration process I've experienced by far. Much MUCH worse than Google or Yahoo or any of them.

We could write a support article about the name and just do it anyway, of course. But once we release this, we absolutely do not want to change the client ID again, because that will produce another round of admins being hit with approval request.

Doesn’t the App Name read Thunderbird on the approval page? Any admin worth his weight would know Thunderbird and Mzla Technologies is probably accurate.

Can you unpublish and republish with a new domain/name ?

You could test doing that in a new app before trying that in this app. Although unpublishing means it will go down until it’s republished, right? It would need to be determined if you can republish quickly after changing the domain (if possibly)

I don't think anybody would understand "Mzla Technologies Corporation", if presented out of context (outside Thunderbird UI).

I thought during approval both the App Name and the Publisher are presented. Published smaller than the app name, in fact.

Maybe I’ll get around to testing to confirm soon enough. We’ll see.

No, it doesn't seem to show the application name at all, which is a pretty bad move by Microsoft(but then, add it to the list). It does show our logo at least.

Right now they've told us that you cannot change the publisher display name on a multi-tenant app, but this doesn't address the fact that even NEW apps still have the old name when I create them, so I can't even make a new one and deal with the client id change.

Duplicate of this bug: 1808020

(In reply to Andrei Hajdukewycz [:sancus] from comment #49)

Created attachment 9309447 [details]
screenshot of MS admin approval page

No, it doesn't seem to show the application name at all, which is a pretty bad move by Microsoft(but then, add it to the list). It does show our logo at least.

Right now they've told us that you cannot change the publisher display name on a multi-tenant app, but this doesn't address the fact that even NEW apps still have the old name when I create them, so I can't even make a new one and deal with the client id change.

Your screenshot shows what a non-admin user sees at Admin Consent. An Admin with granting permissions will see the following (I dont think I can attach an image, so here is plaintext copy):

Microsoft
<admin username redacted>
Permissions requested
Review for your organization
	
Thunderbird
Mzla Technologies Corporation 
This app would like to:

Maintain access to data you have given it access to

Read and write access to mailboxes via IMAP.

Read and write access to mailboxes via POP.

Send emails from mailboxes using SMTP AUTH.

Sign in and read user profile
If you accept, this app will get access to the specified resources for all users in your organization. No one else will be prompted to review these permissions.
Accepting these permissions means that you allow this app to use your data as specified in their terms of service and privacy statement. The publisher has not provided links to their terms for you to review. You can change these permissions at https://myapps.microsoft.com. Show details
Does this app look suspicious? Report it here

If someone watching this bug could check the display name and confirm. I'm pretty sure the eternal nightmare has come to an end and it's finally fixed. It should say "Mozilla Thunderbird" now.

(In reply to Andrei Hajdukewycz [:sancus] from comment #52)

If someone watching this bug could check the display name and confirm. I'm pretty sure the eternal nightmare has come to an end and it's finally fixed. It should say "Mozilla Thunderbird" now.

Confirmed. It shows Mozilla Thunderbird on the admin consent window for both non-admin and admin.

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

[Approval Request Comment]
User impact if declined:
Continued difficulty connecting to Microsoft email servers using IMAP/oAuth.
Testing completed (on c-c, etc.): c-c, beta 107
Risk to taking this patch (and alternatives if risky):
It's possible this will cause more support requests temporarily as people log in and see that their server admin has to approve the new client ID. But there's no way around that other than through it, and we need to make this change to fix many other MS oAuth issues.

Attachment #9297140 - Flags: approval-comm-esr102?

(In reply to Jeremy Reeves from comment #53)

(In reply to Andrei Hajdukewycz [:sancus] from comment #52)

If someone watching this bug could check the display name and confirm. I'm pretty sure the eternal nightmare has come to an end and it's finally fixed. It should say "Mozilla Thunderbird" now.

Confirmed. It shows Mozilla Thunderbird on the admin consent window for both non-admin and admin.

Thanks for your help, this should be able to go into ESR 102.7.0.

Comment on attachment 9297140 [details]
Bug 1685414 - switch Thunderbird to desktop client auth. r=sancus

[Triage Comment]
Approved for esr102

Attachment #9297140 - Flags: approval-comm-esr102? → approval-comm-esr102+
Regressions: 1810760
No longer duplicate of this bug: 1799259
Regressions: 1814823
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: