Untangling the Cross-site Cookie Mess Created by Chrome 84 Update
A recent Chrome update has added the behaviour of blocking all third-party cookies by default. This update was originally supposed to be rolled out in Feb 2020 with Chrome 80, but Google pushed it to Aug 2020 due to COVID-19 situation. Now that this change has been released on Aug 11, 2020, it has caused the chaos as we thought it would.
While third-party cookies can be used to track user behaviour across websites and have privacy implications, Google’s way of throwing the bathwater with the baby by blocking all cross-site cookies prevents even the legit use-cases. One legit use case is Single-Sign-On (SSO). The user authenticates at one location, and then is able to access multiple sites without needing to re-authenticate.
One of the major sites affected by this change seems to Atlassian’s Confluence.
This still works if the authentication URL and site URL are on the same domain (can be on different subdomains) because Google treats all cookies without the SameSite attribute as SameSite=Lax. The cookies are shared within the same domain, but not with the other domains. However, one of the legit use cases is authentication across domains.
One way to resolve this is to ask the user to disable the Chrome behaviour,
- Navigate to
chrome://flags/#same-site-by-default-cookiesin the browser - Select “Disabled” from the dropdown
- Relaunch the browser
But this solution is not scalable.
The recommended solution is to set the SameSite attribute in the authentication cookie with the value SameSite=None. The cookie must also be Secure and has to be served over HTTPS. This articles explain the SameSite attribute very well — https://web.dev/samesite-cookies-explained/.
AWS Classic Load Balancer resolves this by sending two cookies — AWSELB and AWSELBCORS. The AWSELBCORS cookie carries the attribute Secure; SameSite=None.
The quickest way for us to do this by rewriting the cookie with additional attribute in nginx (if that’s what you use for reverse proxying on the server) only for the requests originating from Chrome 80 and above.
map $http_user_agent $samesite_none {
default "";
"~Chrom[^ \/]+\/8[\d][\.\d]*" "; SameSite=None";
}location / {
...
proxy_cookie_path /auth /auth$samesite_none;
...
}
Reload the nginx configuration, and it should work now in regular Chrome window. It still won’t work in Chrome’s “incognito” mode, but this is a start.
