https://github.com/brave/brave-browser/issues/1356#issuecomment-462985058 as per @fmarier.
With shields up, users are not able to authenticate (2FA) on GMail
Token is not accepted. Instead, the following message is displayed:
"Your sign-in attempted timed out…"
User should be able to log into GMail
Always
0.55.10
Tested on Brave (Core) Beta (0.55.10)
Reported on Twitter:
Have the same problem ... can use 2FA by copying the code from the Authenticator app, but not when I try to approve the login on my phone via 2FA prompt.
Hi, for what its worth I did the following observation.
We know that if you allow all cookies for accounts.google.com via the Brave Shield it works.
I deleted all my cookies and only opened the gmail login. When the 2FA popup shows I have the following cookies:

I set the shield back again to default Block 3rd party cookies, deleted all my cookies and allowed cookies on all sites listed above:

When opening gmail again and entering credentials the same thing happens as described in this issue. The only cookies I have now are these:

So something is still blocking cookies, although I allowed them for all listed sites in the settings.
@bas-jansen Looks like the only cookies that got through have the domain google.com. If you allowed the other ones, (youtube.com and googleusercontent.com) wouldn't that just mean that you allowed the cookies _for when you are browsing on those domains_? Which means that when you are logging in on a website with the domain google.com, it's still blocking 3rd party cookies, which I would say is the intended behaviour. Maybe there should be a toggle to allow some specific 3rd party cookies on some specific sites?
+1 experiencing the 2fa issue, specifically with the "select to click yes and confirm from another device" option.
Brave on win10 x64, with 2FA message pushed to Android.
Workaround for me was completely disabling Shields on log in. When my gmail loaded, Shields were enabled again automatically.
Still experiencing this issue on Version 0.56.15 Chromium: 70.0.3538.110 (Official Build) unknown (64-bit)
@tomlowenthal For what it's worth, I just encountered this issue and was able to workaround by disabling shields on accounts.google.com. Perhaps we should restore the workaround/shields-down label?
Still have _a lot_ of users reporting this (myself included). https://www.reddit.com/r/brave_browser/comments/aeyydr/brave_browser_release_channel_has_been_updated_to/ee28nwl/?context=3
@jonathansampson are you able to still repro this on latest release? if so, what 2fa method are you using?
@diracdeltas I have the latest release 0.58.21 and still experience this issue.
I added Google Prompt as a 2FA option in my account and tried to use it by browsing to https://accounts.google.com.
I got the following error in the developer console:
POST https://content.googleapis.com/cryptauth/v1/authzen/awaittx?alt=json&key=AIzaSy... 403
In the successful case, this request hangs as "pending" until I tap "Yes" on my phone. In the failing case, it immediately returns a 403.
If I enable all cookies on accounts.google.com via Shields, it works just fine so this seems related to our third-party cookie blocking.
I compared the cookies in network traces of a successful v. failing flow and saw the same ones being set. Furthermore, the failing POST request never includes any HTTP cookies so it's unclear to me how blocking third-party cookies affects this.
@fmarier perhaps it is a referer issue. 3rd party cookie blocking also blocks 3rd party referer (spoofs it to be the origin of the site that it is going to).
so for instance if user is on gmail.com and makes an XHR to googleapis.com, the referer would be spoofed from gmail.com to https://googleapis.com/
^ to test if this is the fix, you can try adding the relevant domains to IsWhitelistedReferrer in common/shield_exceptions.cc
Fixed in https://github.com/brave/brave-core/pull/1543.
I will prepare PRs for the other branches.
@fmarier any QA verification need for this? Could you please add appropriate test plan in the PR?
@srirambv If you want to, that'd be good. I did test it on all of the branches as I was preparing PRs but I haven't re-tested since.
Steps:
Verification passed on
Brave | 0.60.44 Chromium: 72.0.3626.109Â (Official Build)Â (64-bit)
-- | --
Revision | fae8db7ab9280fa6704a59980263c804f809ebd5-refs/branch-heads/3626@{#857}
OS | Windows 7
Used test plan from https://github.com/brave/brave-browser/issues/1356#issuecomment-462985058
Verification PASSED on macOS 10.14.2 x64 using the following build:
Brave | 0.60.44 Chromium: 72.0.3626.109Â (Official Build)Â (64-bit)
-- | --
Revision | fae8db7ab9280fa6704a59980263c804f809ebd5-refs/branch-heads/3626@{#857}
OS | Mac OS X
Verification PASSED on Mint 19.1 x64 using the following build:
Brave | 0.60.44 Chromium: 72.0.3626.109Â (Official Build)Â (64-bit)
-- | --
Revision | fae8db7ab9280fa6704a59980263c804f809ebd5-refs/branch-heads/3626@{#857}
OS | Linux
I cannot enable 2FA on Github
Brave Version 0.59.35 Chromium: 72.0.3626.81 (Official Build) (64-bit)
macOS Mojave Version 10.14.3 (18D109)
Shields down, use FreeOTP on Android (which works with other browsers) to scan QR and generate code:

@atmin It should be fixed in the next release.
@atmin This bug is about 2FA on Google. It looks like you are running into a different problem (it's on GitHub). Would you mind filing a separate issue for this so that we can track it properly?
Sorry, disregard, false alarm.
I started investigating the issue to file a bug. The reason turned out to be I accidently turned off date/time sync on my phone, so the clock drifted enough to cause invalid auth codes.
Most helpful comment
+1 experiencing the 2fa issue, specifically with the "select to click yes and confirm from another device" option.

Brave on win10 x64, with 2FA message pushed to Android.