12

I have an app that has been running for years with no changes to the code. The app has OAuth2.0 login with a variety of providers including Google Workspace and Office 365. Since the launch of Chrome V97 (i.e. in last few days), the O365 login has stopped working, as for some reason, the auth cookie does not get set in the OAuth callback GET handler. The code that sets the cookie is the same code that is run for Google Workspace, yet this works. It also works on Firefox. Something about Google Chrome V97 is preventing cookies from being set, but only if it round trips to O365 first.

To isolate the issue, I have created a fake callback which manually sets a cookie, thereby removing all of the auth complication. If I call this by visiting the URL in a browser, then the cookie sets as expected. Yet if I perform the O365 OAuth dance first, which in turn invokes this URL, then the cookie does not get set. Try exactly the same thing with Google Workspace and it works.

I have been debugging this for hours and hours and clean out of ideas.

Can anyone shed any light on what could be causing this odd behaviour?

Gwyn Howell
  • 5,365
  • 2
  • 31
  • 48
  • 2
    I am facing the same issue, with both Google and Microsoft Oauth. Everything works perfectly on Chrome 96 and below, as well as Firefox and Safari. Regular sign in with a password works just fine which leads me to believe this is a change in SameSite Lax behaviour in Chrome 97. Would love some direction on solving this as well! – hash12 Jan 08 '22 at 12:42
  • 2
    I have now replicated with Google OAuth as well. Looks to be an issue introduced with Chrome97. I have a support ticket open with the chrome team. Will update this thrad if I get an update. – Gwyn Howell Jan 10 '22 at 11:45
  • 2
    Chrome 97 broke SSO on our website, very interested in Chrome team response – samfromlv Jan 13 '22 at 16:04
  • @GwynHowell by any chance does your application use service workers? Most Chrome changes related to SameSite cookies were implemented in Chrome 80, but I found [this change for Chrome 97](https://chromestatus.com/feature/5752539724120064) which affects how SameSite status is determined for requests from service workers specifically. I am troubleshooting a similar issue with AzureAD auth on an app that uses a service worker on the frontend. – nhinkle Jan 19 '22 at 03:38
  • I just did a test where I disabled the service worker for my site (removed service-worker.js on the server, cleared all in the applications tab in the chrome web inspector, and reloaded the page) and the cookie/authentication issue does not occur. – nhinkle Jan 19 '22 at 03:45

3 Answers3

8

We ran into this too, fixed by adding SameSite=none; to the auth cookie. In Chrome 97 SameSite is set to Lax if missing. See more here https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

kulesa
  • 2,964
  • 20
  • 11
  • The SameSite=None works for us too, but I don't understand why. The cookies we are using should not be shared with third parties so if anything, the value should be SameSite=Strict. Can anyone shed any light on this? – Gwyn Howell Jan 13 '22 at 15:23
4

Can confirm adding SameSite=none worked for me as well.

For anyone seeing this issue in a .Net Core Identity app, make sure you are configuring the ExternalCookie, not the ApplicationCookie. Here is the relevant code:

services.ConfigureExternalCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.None;
});
jbarnes
  • 86
  • 3
3

Using SimpleSamlPHP library (v1.19 above), we need to set samesite.cookie to 'none' and secure.cookie to true resolve the issue. This issue noticed on recent chrome / chromium upgrade to v97

'session.cookie.secure' => true,
'session.cookie.samesite' => \SimpleSAML\Utils\HTTP::canSetSameSiteNone() ? 'None' : null,

This will set same cookie site flag to "None" in Chrome browser and "secure" flag on cookies.

Jagan
  • 431
  • 2
  • 2