Investigate cross-origin cookie issues

[stefandesu]

I've had mixed results working with Safari, so some investigation is necessary. As this site reports that cross-site cookies with SameSite=None; Secure do work in Safari, they don't seem to work with Login Server so far. Here is the source code for that site, so I'll test it out myself and see whether I can get it to work here as well.

[stefandesu]

I did some experimentation and found out a curious thing: By default, even for SameSite=None; Secure cookies, these cookies are not sent with a cross-site request. However, if we use window.open to open the login page for login-server, and then interact with the site, it will start sending cookies for cross-site requests. This seems to be some security mechanism in Safari. However, I'm really unsure how to circumvent this. In theory, we could try to detect Safari and develop some natural workflow in which the user interacts with the site, or something like that.

The weird thing however is that it's hard to find any documentation about this anywhere. I feel like I'm missing something obvious...

[stefandesu]

This site says the following:

Unless you visit and interact with the third-party content provider as a first-party website, their cookies and website data are deleted.

So that explains the behavior I think. However, there should be a way around this without a weird hack.

[stefandesu]

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/:

If yours is among the few websites that still relies on third-party cookies in Safari and has not been affected by ITP in its previous iterations, here’s how you can make things work for your users:

Option 1: OAuth 2.0 Authorization with which the authenticating domain (in your case, the third-party that expects cookies) forwards an authorization token to your website which you consume and use to establish a first-party login session with a server-set Secure and HttpOnly cookie.

Option 2: The Storage Access API with which the third-party can request permission to get access to its first-party cookies.

Option 3: The temporary compatibility fix for popups, see section “Temporary Compatibility Fix: Automatic Storage Access for Popups” in our ITP 2.0 blog post. This compatibility fix allows the third-party to open a popup from your website and upon a tap or click in that popup gain temporary cookie access under the opener page on your website. Note that this compatibility fix will go away in a future version of Safari so only go this route if it saves you time and allows for a graceful transition period.

Option 3 is the one I've been thinking about, but they explicitly say that it'll go away in the future. So I guess I'll try to look into the other two options at some point...

[nichtich]

With #61 it should be possible to detect whether login-server is used cross-site and a warning could be shown for Safari users.

[stefandesu]

It is already possible in login-client with LoginClient.errors.ThirdPartyCookiesBlockedError. This issue is about fixing the problem. I'm 99.9% sure that there is a solution since other services are doing it as well.

[stefandesu]

Since Chrome (Chromium) also plans to abandon third-party cookies completely, we need to find an alternative, long-term solution for this issue.

Here are some resources we might look into for help:

• https://stackoverflow.com/a/342498/11050851 (SSO explained simply, using redirects with URL params)
• Explanation about how the StackExchange group achieves this with their different domains:
  • https://meta.stackexchange.com/a/64274
  • https://stackoverflow.blog/2010/09/11/global-network-auto-login/
• https://www.indiehackers.com/post/authentication-across-sub-domains-239245e7a1
  • This talks about different subdomains of the same domain (which should be able to simply use cookies), but there are some more infos in the comments.
  • Also this video was mentioned in one comment: https://www.youtube.com/watch?v=SLc3cTlypwM

[nichtich]

What's the difference of this issue compared to #90?

[nichtich]

Just an idea: the same login-server database might be shared across multiple instances at different domains, e.g. coli-conc.gbv.de/login and bartoc.org/login - or extend login-server to support multiple BASE_URL in parallel and use proxy to server under different domains.

[nichtich]

Hosting the same instance on multiple domains will not work because identity providers require a unique domain name to be registered. Current most viable solution is to use one instance for each domain (primary) but possibly sync instances (secondary). Final solution may be postponed before #32 anyway as SAML seems to work across domains.