4 ms·

Privacy wins aside, can anyone please help educate if third party single sign ons will still continue to work?

kayodelycaon 4y ago
This feature protects domains, not sessions. SSO relies on passing tokens over redirects, not cookies. As long as your redirected, the SSO uses their own first party cookies. You would be logged in to the SSO provider no matter who redirected you there.
ezfe 4y ago
Single sign on doesn't need cookies. The data is passed in the URL when redirecting back and forth between the website and the SSO provider.
jalk 4y ago
I don't think they rely on third party cookies. You are redirected to the SSO provider which then issues a token which it transports back to the requesting site through other means than cookies (i.e. post body / query string)
Strom 4y ago
Depends on the specific implementation, but in theory this doesn't limit any functionality for SSO. Data can be shared via mechanisms other than cookies.
wisniewskit 4y ago
It depends on the specific third party login service. Some rely on third party storage-sharing, and there are web compatibility measures built into Total Cookie Protection to allow those to keep working. One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place. In these cases, specific third parties can be granted access to allow the login. There are some more details here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...
three14 4y ago
And can someone explain how I'm supposed to implement SSO? We have a bunch of subdomains that support SSO by communicating with an iframe that has the logon status stored, but it appears that the iframe wouldn't have access to its own data anymore. Is that right?
- notriddle 4y ago
  Subdomains shouldn't be a problem unless your base domain is in the Public Suffix List. According to MDN: > More specifically, Firefox double-keys all client-side state by the origin of the resource being loaded and by the top-level site. [1] They linked the definition of a "site" to the HTML5 spec, which says this: > To obtain a site, given an origin origin, run these steps: [2] > 1. If origin is an opaque origin, then return origin. > 2. If origin's host's registrable domain is null, then return (origin's scheme, origin's host). > 3. Return (origin's scheme, origin's host's registrable domain). The HTML5 spec refers to the site's registrable domain according to the URL spec: > A host’s registrable domain is a domain formed by the most specific public suffix, along with the domain label immediately preceding it, if any. [3] Public Suffixes are defined according to a database that you have to explicitly register in [4]. If you aren't sure whether your base domain is registered as a public suffix, then it probably isn't. [1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P... [2]: https://html.spec.whatwg.org/multipage/origin.html#site https://html.spec.whatwg.org/multipage/origin.html#site [3]: https://url.spec.whatwg.org/#host-registrable-domain https://url.spec.whatwg.org/#host-registrable-domain [4]: https://publicsuffix.org/ https://publicsuffix.org/
  - three14 4y ago
    Thanks! I actually got as far as your [1], but incorrectly assumed that 'site' meant 'origin', so thank you for explaining.

This feature protects domains, not sessions. SSO relies on passing tokens over redirects, not cookies. As long as your redirected, the SSO uses their own first party cookies. You would be logged in to the SSO provider no matter who redirected you there.

ezfe 4y ago

Single sign on doesn't need cookies. The data is passed in the URL when redirecting back and forth between the website and the SSO provider.

jalk 4y ago

I don't think they rely on third party cookies. You are redirected to the SSO provider which then issues a token which it transports back to the requesting site through other means than cookies (i.e. post body / query string)

Strom 4y ago

Depends on the specific implementation, but in theory this doesn't limit any functionality for SSO. Data can be shared via mechanisms other than cookies.

wisniewskit 4y ago

It depends on the specific third party login service. Some rely on third party storage-sharing, and there are web compatibility measures built into Total Cookie Protection to allow those to keep working. One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place. In these cases, specific third parties can be granted access to allow the login. There are some more details here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...

three14 4y ago

And can someone explain how I'm supposed to implement SSO? We have a bunch of subdomains that support SSO by communicating with an iframe that has the logon status stored, but it appears that the iframe wouldn't have access to its own data anymore. Is that right?

notriddle 4y ago
Subdomains shouldn't be a problem unless your base domain is in the Public Suffix List. According to MDN: > More specifically, Firefox double-keys all client-side state by the origin of the resource being loaded and by the top-level site. [1] They linked the definition of a "site" to the HTML5 spec, which says this: > To obtain a site, given an origin origin, run these steps: [2] > 1. If origin is an opaque origin, then return origin. > 2. If origin's host's registrable domain is null, then return (origin's scheme, origin's host). > 3. Return (origin's scheme, origin's host's registrable domain). The HTML5 spec refers to the site's registrable domain according to the URL spec: > A host’s registrable domain is a domain formed by the most specific public suffix, along with the domain label immediately preceding it, if any. [3] Public Suffixes are defined according to a database that you have to explicitly register in [4]. If you aren't sure whether your base domain is registered as a public suffix, then it probably isn't. [1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P... [2]: https://html.spec.whatwg.org/multipage/origin.html#site https://html.spec.whatwg.org/multipage/origin.html#site [3]: https://url.spec.whatwg.org/#host-registrable-domain https://url.spec.whatwg.org/#host-registrable-domain [4]: https://publicsuffix.org/ https://publicsuffix.org/
- three14 4y ago
  Thanks! I actually got as far as your [1], but incorrectly assumed that 'site' meant 'origin', so thank you for explaining.