Can't login to SharePoint account on Brave

[ShivanKaul]

Description

Brave goes into a long redirect loop when trying to login to https://unomail.sharepoint.com/. This started happening on ~Feb 28 2024, and presumably because of a website auth flow change. It does not look related to Shields or privacy protections, the breakage happens even with the following:

1. Shields down for both unomail.sharepoint.com and login.microsoftonline.com
2. Tracker, fingerprinting, HTTPS upgrades, De-AMP, debouncing all set to Disabled
3. 3P cookies globally allowed

https://unomail.sharepoint.com/ works fine on Safari, FF, Chrome, DDG. Brave only has troubles with SharePoint, regular login via login.microsoftonline.com directly works fine.

Community reports:

1. https://community.brave.com/t/unable-to-login-into-microsoft-account-in-brave-browser-but-working-fine-for-other-browsers/534041/4
2. https://community.brave.com/t/cannot-log-in-to-corporate-microsoft-sharepoint/534039

Steps to Reproduce

1. Go to https://unomail.sharepoint.com/
2. Try logging in with regular MS account

Actual result:

There's a number of redirects between unomail.sharepoint.com and login.microsoftonline.com

The network activity looks like this:

1. POST to https://unomail.sharepoint.com/_forms/default.aspx returns a 302 to https://login.microsoftonline.com:443/f1f4be86-d048-47e8-aa26-15b01dcdb13d/oauth2/authorize?client%5Fid=...
2. GET to that redirected URL is 200
3. But then another POST request to https://unomail.sharepoint.com/_forms/default.aspx is started which gets a 302, etc.

Expected result:

Either logged in or if there's no SharePoint account, a page that says that your account can't be found in the unomail.sharepoint.com directory.

Reproduces how often:

Always

Brave version (brave://version info)

1.65.6 Chromium: 122.0.6261.43 (Official Build) nightly (arm64)
Happens on all Brave versions

[ShivanKaul]

Just to give an update here, setting Brave's User Agent to be a non-Chromium one i.e. Firefox's or Safari's seems to fix the issue.

[dovecode]

I believe I have identified the root cause of this issue. When Sharepoint initiates the authentication, it sets a cookie (from /_forms/default.aspx on my employer's Sharepoint -- not sure if that's standard). However, if the browser identifies as a Chromium based browser, it also clears the cookie in the same response. Essentially:

Set-Cookie: <cookiename>=<unique value>; expires=<timestamp>; path=/; SameSite=None; secure; HttpOnly
Set-Cookie: <cookiename>=; expires=<timestamp>; path=/; SameSite=None; Partitioned; secure; HttpOnly

Google Chrome reacts to this as either clearing first, then setting it, or clearing the partitioned cookie type and setting the non-partitioned one, while Brave just clears is.

As a result, post-authentication when the authentication provider redirects back to default.aspx, the cookie is missing and Sharepoint goes into a tailspin.

[ShivanKaul]

I'll take a look in a bit, but this does seem likely, we noticed some discrepancies in how cookies were being sent in the request for default.aspx between Brave/Chrome/others.

[dovecode]

I'll take a look in a bit, but this does seem likely, we noticed some discrepancies in how cookies were being sent in the request for default.aspx between Brave/Chrome/others.

Yeah. It looks like for Google Chrome if does set the cookies the same as for Brave (it probably looks at the user agent and goes "ah, Chromium, it can handle non-RFC6267-compliant cookie headers"), while for Firefox, it only sets the cookie, it doesn't clear the CHIP cookie. That's how I found I could work around the bug by spoofing Firefox.

[cb3inco]

Same issue here (Linux OS) started yesterday, but feels more like a SharePoint issue. In another profile with another Microsoft account, no issue, so it's a bit weird, unless it's because I refreshed an authentication token yesterday on the broken profile. I also tested on my Android device as well and ran into the same issue.

[ShivanKaul]

@dovecode #36450 (comment) catch looks correct to me.

For Brave (and FF), all cookies are partitioned, so a cookie being marked as Partitioned is a no-op, but because of that if you set the value of a cookie A=1 and then in a different call A=2; Partitioned, from Brave's pov, it's the same cookie so the value of cookie A is just 1, while in Chrome, it will have two cookies A=1 and A=2; Partitioned.

I can't think of why SharePoint needs to do both clearing for the nSGt-* Partitioned cookie and setting a value for the same unpartitioned cookie, but yeah Chrome treats that as two separate cookies while Brave just clears the cookie, causing the repeated looping.

brave/brave-core#22391 will fix this.

[kjozwiak]

The above requires 1.63.168 or higher for 1.63.x verification 👍

[syaikhipin]

Same issue here with sharepoint

[mmcdougall2]

I hope Brave gets this fixed soon. I HATE M$ Edge!

[ibnuharisfawaid]

Me too, i'm having with this issue.

[TheBule88]

I'm also seeing the same issue.

[goodov]

We rolled a fix for the issue via Griffin. It should be applied after a browser restart.

To check if it's there, please open brave://version and look for PartitionedCookies:Enabled line in the Active Variations list.

[Cyb3rN0de]

Also having this issue. Started today on my Mac only using Brave, however Brave on Kali Linux is still working fine.

[TheBule88]

We rolled a fix for the issue via Griffin. It should be applied after a browser restart.

To check if it's there, please open brave://version and look for PartitionedCookies:Enabled line in the Active Variations list.

Can confirm that this fixed the issue for me!

[ibnuharisfawaid]

We rolled a fix for the issue via Griffin. It should be applied after a browser restart.

To check if it's there, please open brave://version and look for PartitionedCookies:Enabled line in the Active Variations list.

Awesome, it was fixed

[cheflA1]

Same issue for me.
I don't quite understand that "fix". I would just like it to work again without all those modifications.

[AUfferte]

Same issue for me. I don't quite understand that "fix". I would just like it to work again without all those modifications.

Restart your browser/computer
It just made the update automatically and worked for me

[LaurenWags]

Verified the below with

Brave | 1.63.168 Chromium: 122.0.6261.94 (Official Build) (x86_64)
-- | --
Revision | 08196d502fa95681adc6dd9fc06a04d0664ac538
OS | macOS Version 13.6.4 (Build 22G513)

Per brave/brave-core#22391 (comment), verified the test cases from https://dev-pages.brave.software/storage/ephemeral-storage.html:

• Cross-site cookies blocked - PASSED
• Cookies Blocked - PASSED
• All cookies allowed - PASSED

cc @kjozwiak for the remaining check on macOS

[hffvld]

Verified on Pixel 7 using version(s):

Device/OS: Pixel 7 / panther_beta-user 14 AP21.240119.009 release-keys
Brave build: 1.63.168
Chromium: 122.0.6261.94 (Official Build) (64-bit) 

---

STEPS:

1. Launch Brave
2. Go to https://unomail.sharepoint.com/
3. Try logging in with a regular MS account > Verify

ACTUAL RESULTS:

• Verified that the page says That didn't work and your account can't be found in the unomail.sharepoint.com directory are shown when signing in with a regular MS account to https://unomail.sharepoint.com/

---

1	2

[Uni-verse]

Verified on Samsung Galaxy Tab S7 using version:

Brave	1.63.168 Chromium: 122.0.6261.94 (Official Build) (64-bit) 
Revision	08196d502fa95681adc6dd9fc06a04d0664ac538
OS	Android 13; Build/TP1A.220624.014; 33; REL

• Ensured logging into https://unomail.sharepoint.com/ will present That didn't work page instead of something went wrong

• Ensured ephemeral storage tests in https://dev-pages.brave.software/storage/ephemeral-storage.html for Brave pre-1.64.31 configuration are successfully passing.

  • Cross-site cookies blocked
  • Cookies blocked
  • All cookies allowed

1.63.165	1.63.68	version

[MadhaviSeelam]

Verification PASSED using

Brave | 1.63.168 Chromium: 122.0.6261.94 (Official Build) (64-bit)
-- | --
Revision | 08196d502fa95681adc6dd9fc06a04d0664ac538
OS | Windows 11 Version 23H2 (Build 22631.3155)

Reproduced the issue in 1.63.162 Chromium: 122.0.6261.69

1. Installed 1.63.165
2. launched Brave
3. logged into https://unomail.sharepoint.com/ with Microsoft account
4. confirmed That didn't work... can't be found in the unomail.sharepoint.com directory message shown as expected since I do not have Sharepoint account.

verified the test cases from https://dev-pages.brave.software/storage/ephemeral-storage.html for Brave pre-1.64.31+ with Chromium storage partitioning.

• Cross-site cookies blocked - PASSED
• Cookies Blocked - PASSED
• All cookies allowed - PASSED

[kjozwiak]

cc @kjozwiak for the remaining check on macOS

Verification PASSED on macOS Senoma 14.3.1 x64 using the following build(s):

Brave | 1.63.168 Chromium: 122.0.6261.94 (Official Build) (x86_64)
--- | ---
Revision | 08196d502fa95681adc6dd9fc06a04d0664ac538
OS | macOS Version 14.3.1 (Build 23D60)

Visited https://unomail.sharepoint.com and ensured that the error displays That didn't work and not Something went wrong as mentioned via #36450 (comment).

[kjozwiak]

Verification PASSED on Ubuntu 22.04 x64 using the following build(s):

Brave | 1.63.168 Chromium: 122.0.6261.94 (Official Build) (64-bit)
--- | ---
Revision | 08196d502fa95681adc6dd9fc06a04d0664ac538
OS | Linux

Using the STR/information detailed via #36450 (comment), ensured that logging into https://unomail.sharepoint.com produced an error message as I don't have a Sharepoint account rather than failing via Something went wrong as per the following:

Also went through https://dev-pages.brave.software/storage/ephemeral-storage.html and verified that all the tests passed as per:

Using Brave 1.64.31+ with Chromium storage partitioning, ensured all three tests/shield states passed as per:

• Cross-site cookies blocked - PASSED
• Cookies Blocked - PASSED
• All cookies allowed - PASSED

[mt-drunkdragon]

It seems to be fixed without Bave update. Mine is 1.63.169.
Maybe MS did something...

[mephinet]

Can confirm: upgrading to 1.63.169 fixes the issue. Thanks for the quick solution!

[dovecode]

It seems to be fixed without Bave update. Mine is 1.63.169. Maybe MS did something...

Nah, 1.63.169 is the upgrade that works around MS's non-RFC6267-compliant cookies. I can confirm that Sharepoint still sends two Set-Cookie headers with the same cookie name.

[mmcdougall2]

Mine works now, but I don't know what changed. Thanks! ***@***.***<http://www.dallascitynews.net/> Mike McDougall Sr. Systems Admin City of Dallas | DallasCityNews.net CIS 1500 Marilla, 3ES Dallas, TX 75201 O: 214-670-3466 ***@***.******@***.***> ***@***.*** <https://twitter.com/CityofDallas> ***@***.*** <https://www.facebook.com/DallasCityHall/> ***@***.*** <https://www.youtube.com/user/dmcclel> **OPEN RECORDS NOTICE: This email and responses may be subject to the Texas Open Records Act and may be disclosed to the public upon request. Please respond accordingly.** From: Nicolai Nielsen ***@***.***> Sent: Friday, March 8, 2024 7:56 AM To: brave/brave-browser ***@***.***> Cc: McDougall, Mike ***@***.***>; Comment ***@***.***> Subject: Re: [brave/brave-browser] Can't login to SharePoint account on Brave (Issue #36450) External Email! It seems to be fixed without Bave update. Mine is 1.63.169. Maybe MS did something... Nah, 1.63.169 is the upgrade that works around MS's non-RFC6267-compliant cookies. I can confirm that Sharepoint still sends two Set-Cookie headers with the same cookie name. - Reply to this email directly, view it on GitHub<#36450 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH4RZMQQNWUFI3Z53EHKIODYXG7PLAVCNFSM6AAAAABD654IESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBVG4ZTQOBYGY>. You are receiving this because you commented.Message ID: ***@***.******@***.***>> CAUTION: This email originated from outside of the organization. Please, do not click links or open attachments unless you recognize the sender and know the content is safe.