search

gbv / login-server

Login and connect accounts with multiple identity providers
https://coli-conc.gbv.de/login/
MIT License
32 stars 32 forks source link

Investigate cross-origin cookie issues #63

Open stefandesu opened 3 years ago

stefandesu commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

nichtich commented 1 year ago

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