Thanks for mentioning this. I've poured through docs on SameSite and none seem to mention subdomains or what setting is required for a cookie set at root Domain to be shared with subdomains.
Apparently browsers will use the public suffix list to determine what constitutes the first part of a domain which is identifying, and anything beyond that is considered SameSite.
So www.foo.com is the same site as api.foo.com, but user1.github.io is not the same site as user2.github.io. Because github.io is on the public suffix registry.
That is according to web.dev anyway...
"SameSite" affects sending the cookie in situations where top-level site in the browser context is different from the target site of the request where the browser is determining if it should send cookies. e.g. on example.site with an iframe to widget.site
"Domain" determine the the highest level domain to which cookies should be sent, regardless of the browsing context. e.g. on example.site an iframe on widgets.example.site or top-level navigation to accounts.example.site
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... details: > * If omitted, defaults to the host of the current document URL, not including subdomains. > * If a domain is specified, subdomains are always included.
I have a couple of setups where an application has a single sign-on for root and subdomains. The shared cookie has the Domain attribute set to the root domain, but (so far) they have no explicit SameSite attribute.
I searched around and came to the conclusion that the above setup will behave the same way with new default SameSite=Lax. However, there wasn't a canonical reference that I could point to, to prove this works as I expect.