1834062 - Microsoft OAuth2 "Sign in with a different account" link has disappeared (for custom login screens)

Status: RESOLVED INVALID

(Thunderbird :: Security, defect)

Description

[Julian Field]

Attachment: Screenshot from TB 114.0b3.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

I have a main Office365 mailbox "[e-mail]". I have access to a shared mailbox (whose account has no password set) "[e-mail]".

1. In TB, create an IMAP account using OAuth2 authentication for [e-mail].
2. Attempt to connect to this account by clicking on the "Inbox" folder.
3. MS OAuth2 window appears asking for password for [e-mail].

Actual results:

There is no option available other than to enter a password for [e-mail], which doesn't exist.

Expected results:

Up until a couple of weeks ago, there was a "Sign in with another account" link in that window that would enable me to switch so I could login as [e-mail], which has access to the stutor mailbox.

Comment 1

[Julian Field]

I normally run the latest Supernova beta, currently 114.0b3.

It appears bug 1810760 has re-appeared in the past couple of weeks.
It also happens in production versions after 102.7.0.
Version 102.6.1 behaves correctly.
Bug 1810760 was marked "RESOLVED" 4 months ago, but clearly this bug is still present.

Comment 2

[Magnus Melin [:mkmelin] (away until Aug 10)]

Content in that window is fully controlled by Microsoft (and partners).

Comment 3

[Julian Field]

But Magnus, the content of that window depends on headers sent in the OAuth2 request apparently.
If you downgrade to TB 102.6.1 then it behaves correctly and the extra "Sign in with a different account" link appears as expected.
Upgrade to 102.7.0 or later and the link disappears.
The problem of the disappearance of this link can be fixed by TB. I'm not saying its disappearance very recently is solely down to TB.
Please see bug 1810760 as I mentioned above.

Comment 4

[Magnus Melin [:mkmelin] (away until Aug 10)]

Attachment: image.png

It's certainly possible MS does something different depending on a number of factors. But I don't know what factors those would be.

I do get the "sign in with another account" link when I try it. Perhaps it's depending you what your university configured...

Comment 5

[Julian Field]

Then why does the MS box behave differently between TB 102.6.1 and 102.7.0?
It sounds like a connection with this header difference between those 2 versions as discussed in the bug I keep referring to.

Comment 6

[Magnus Melin [:mkmelin] (away until Aug 10)]

More likely since the app id changed (bug 1685414). But there's no knowing what their servers may be looking at, for whichever circumstances.
Have you tried asking the university IT what they could fix here? The "basic" OAuth shows the link, as you can see in comment 4.

Comment 7

[spam.robert]

I am having the same issue, as in the sign in field not showing up anymore.
Our admin is happy to try out settings on the 365 instance, but could not find anything yet. So, I am looking for ideas to try those out.

What I noticed being different to the example above that worked (In reply to Magnus Melin [:mkmelin] from comment #4), and how our window looked is the url. Example of our url (note the items between [] have been altered). It seems that the screenshot at the top of the thread has a similarly long url.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=code&client_id=[client-id]&redirect_uri=https%3A%2F%2Flocalhost&scope=https%3A%2F%2Foutlook.office365.com%2FIMAP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FPOP.AccessAsUser.All+https%3A%2F%2Foutlook.office365.com%2FSMTP.Send+offline_access&login_hint=[some-email-address]

Comment 8

[Magnus Melin [:mkmelin] (away until Aug 10)]

That's the authorizationEndpoint. When you go there the server should show a page allowing you to "allow" whatever is needed - but before it can do that it needs to know who you are and will put you through the login process - whatever that looks like (redirect or something inline).
The org of the OP in this bug apparently deploys a custom login scheme. Perhaps the same for you.

Comment 9

[spam.robert]

You are correct, we do deploy a custom login screen. As suggested by OP I also tried out TB 102.6.1, and indeed got the log in as another account button again, which worked flawless in this case. Note the only customisation deployed to the login screen is a different background from the standard MS one, so I do not see the solution to be on the IT side.

Comment 10

[Magnus Melin [:mkmelin] (away until Aug 10)]

I think whoever handles the login screen customization at your org needs to contact Microsoft and get their input on why it's different.

Comment 11

[Wayne Mery (:wsmwk)]

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

More likely since the app id changed (bug 1685414). But there's no knowing what their servers may be looking at, for whichever circumstances.
Have you tried asking the university IT what they could fix here? The "basic" OAuth shows the link, as you can see in comment 4.

Julian?

Comment 12

[tniagcpm]

Attachment: Standard login screen - no change account

I have been affected by this issue since version but with a standard login screen.
102.6 was the last version that I could use to connect to a Shared Mailbox.
Later versions give me a login screen with no option to change account.

Comment 13

[tniagcpm]

Attachment: Alternate login screen - no change account option

This is the alternate standard login screen I see - for a password entry.
Note no "Sign in with another account".

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to tniagcpm from comment #13)

Created attachment 9344536 [details]
Alternate login screen - no change account option

This is the alternate standard login screen I see - for a password entry.
Note no "Sign in with another account".

Still, that content is determined by the provider.

Perhaps this is best discussed at https://thunderbird.topicbox.com/groups/enterprise