3 ms·

Authentication, notably OAuth, from all of the large major providers comes from a domain other than the site content domain. Blocking third party cookies indisc

Authentication, notably OAuth, from all of the large major providers comes from a domain other than the site content domain. Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens.

peeters 6y ago
3rd-party cookies aren't actually intrinsic to OIDC auth flows. They might be used by some implementations under some flows, but they're not core to the spec. Typically the user agent will redirect to a Google/etc login page where it'll have access to first-party cookies. Then will redirect back to the site which requested authentication, passing state in the query params. It's only when you get into using stuff like Okta as a delegated authentication service do you run into trouble with 3rd party cookies. Edit: As an example, I just logged into Stackoverflow using Google as the authenticator, with umatrix blocking 3rd-party cookies. Worked without a hitch.
drtillberg 6y ago
The extent to which my browser configuration breaks the websites on your list is my yardstick for success.
michaelt 6y ago
No it doesn't. The user clicks 'log in with google', their browser gets forwarded to whatever.google.com, the (now first party) cookie gets checked, then the user gets forwarded back to your site with the access token as a parameter in the GET request. No third party cookies needed.
cesarb 6y ago
> Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens. I block third party cookies indiscriminately, and I never had issues logging into Facebook, Google, Twitter, or any Microsoft service except for Microsoft Teams. This includes logging into third-party services using the Google login.

peeters 6y ago

3rd-party cookies aren't actually intrinsic to OIDC auth flows. They might be used by some implementations under some flows, but they're not core to the spec. Typically the user agent will redirect to a Google/etc login page where it'll have access to first-party cookies. Then will redirect back to the site which requested authentication, passing state in the query params. It's only when you get into using stuff like Okta as a delegated authentication service do you run into trouble with 3rd party cookies. Edit: As an example, I just logged into Stackoverflow using Google as the authenticator, with umatrix blocking 3rd-party cookies. Worked without a hitch.

drtillberg 6y ago

The extent to which my browser configuration breaks the websites on your list is my yardstick for success.

michaelt 6y ago

No it doesn't. The user clicks 'log in with google', their browser gets forwarded to whatever.google.com, the (now first party) cookie gets checked, then the user gets forwarded back to your site with the access token as a parameter in the GET request. No third party cookies needed.

cesarb 6y ago

> Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens. I block third party cookies indiscriminately, and I never had issues logging into Facebook, Google, Twitter, or any Microsoft service except for Microsoft Teams. This includes logging into third-party services using the Google login.