Hacker News Reader

Comment by rdsubhas | Hacker News Reader

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

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...

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)

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.

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.

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.

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?

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_P...

[2]: https://html.spec.whatwg.org/multipage/origin.html#site

[3]: https://url.spec.whatwg.org/#host-registrable-domain

[4]: https://publicsuffix.org/

Thanks! I actually got as far as your [1], but incorrectly assumed that 'site' meant 'origin', so thank you for explaining.

Reply on news.ycombinator.com