Use of SameSite with authenticated user-content domains

[nicktrav]

trafficstars

We are running into an issue in the case of user-content domain protected by an BeyondCorp style authenticating proxy, and are hoping for some guidance in best practices in this type of (increasingly common) setup.

Consider a primary domain, foo.com, and a companion "user content" domain, foo-usercontent.com. The latter is used for arbitrary user content uploads and various static assets (CSS, JS, etc.), following web best practices.

Both domains are protected by a BeyondCorp style authenticating proxy, that uses JWTs for authentication of every request. The same JWT can be used for authenticating on either domain. The JWT is set without the SameSite directive.

Visiting foo.com issues an initial request that uses the cookie for foo.com in a first-party context, and returns content that must now be fetched from foo-usercontent.com.

Prior to Chrome v80, the Cookie with the JWT would be sent on requests to foo-usercontent.com, allowing them to be authenticated, and content fetched.

Post Chrome v80, we get the familiar message about the Cookie being blocked from being used. As a result, static content cannot be fetched from the foo-usercontent.com domain, as the request is treated as unauthenticated due to the missing JWT token. The pages do not render correctly, resulting in a confusing user experience. The obvious workaround is, most unfortunately, to disable the #same-site-by-default-cookies feature.

We asked the vendor of the authenticating proxy whether they would be willing to set SameSite=None on the cookie and allow it to be used in cross-site requests to the user-content domain. The answer was that there were no plans to change the behavior here.

The question(s):

Does the lack of SameSite directive, and the resultant interpretation of SameSite=Lax, make sense in a situation like this?

Would there be any valid argument, from security perspective, in setting SameSite=None for this authentication cookie, allowing the cookie to be sent on requests for foo-usercontent.com in a third-party context, as it was before.

[nicktrav]

The answer was that there were no plans to change the behavior here.

This has since changed, but my questions still stand on this, and the answers may be useful to others looking to use cookies when a user-content domain setup is in place.

[rowan-m]

Thoughts on this:

• Is it necessary for these to be wholly separate sites as opposed to separate sub-domains? e.g. foo.com and usercontent.foo.com. Requests between these would not be cross-site and SameSite=Lax would work as expected.
• If they need to be separate sites, this might be solved in the long-term by something like First-Party Sets however this is still an early stage proposal.
• If you're running a proxy, you may have the option of transforming cookies yourself on those requests if it is not possible to update the underlying system. I have a very rough proof-of-concept here.