Cross-Domain Cookies

The smartest solution is to follow facebook's path on this. How does facebook know who you are when you visit any domain? It's actually very simple:

The Like button actually allows Facebook to track all visitors of the external site, no matter if they click it or not. Facebook can do that because they use an iframe to display the button. An iframe is something like an embedded browser window within a page. The difference between using an iframe and a simple image for the button is that the iframe contains a complete web page – from Facebook. There is not much going on on this page, except for the button and the information about how many people have liked the current page.

So when you see a like button on cnn.com, you are actually visiting a Facebook page at the same time. That allows Facebook to read a cookie on your computer, which it has created the last time you’ve logged in to Facebook.

A fundamental security rule in every browser is that only the website that has created a cookie can read it later on. And that is the advantage of the iframe: it allows Facebook to read your Facebook-cookie even when you are visiting a different website. That’s how they recognize you on cnn.com and display your friends there.

Source:

• http://dorianroy.com/blog/2010/04/how-facebooks-like-button-works/
• https://stackoverflow.com/a/8256920/715483

Cross-domain cookies are not allowed (i.e. site A cannot set a cookie on site B).

But once a cookie is set by site A, you can send that cookie even in requests from site B to site A (i.e. cross-domain requests):

XMLHttpRequest from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request. The third-party cookies obtained by setting withCredentials to true will still honor same-origin policy and hence can not be accessed by the requesting script through document.cookie or from response headers.

Make sure to do these things:

1. When setting the cookie in a response
   • The Set-Cookie response header includes SameSite=None if the requests are cross-site (note a request from www.example.dev to static.example.dev is actually a same-site request, and can use SameSite=Strict)
   • The Set-Cookie response header should include the Secure attribute if served over HTTPS; as seen here and here
2. When sending/receiving the cookie:
   • The request is made with withCredentials: true, as mentioned in other answers here and here, including the original request whose response sets the cookie set in the first place
     • For the fetch API, this attribute is credentials: 'include', vs withCredentials: true
     • For jQuery's ajax method, note you may need to supply argument crossDomain: true
   • The server response includes cross-origin headers like Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Headers, and Access-Control-Allow-Methods
     • As @nabrown points out: "Note that the "Access-Control-Allow-Origin" cannot be the wildcard (*) value if you use the withCredentials: true" (see @nabrown's comment which explains one workaround for this.
3. In general:
   • Your browser hasn't disabled 3rd-party cookies. (* see below)

Things that you don't need (just use the above):

1. domain attribute in the Set-Cookie; you can choose a root domain (i.e. a.example.com can set a cookie with a domain value of example.com, but it's not necessary; the cookie will still be sent to a.example.com, even if sent from b.other-site.example
2. For the cookie to be visible in Chrome Dev Tools, "Application" tab; if the value of cookie HttpOnly attribute is true, Chrome won't show you the cookie value in the Application tab (it should show the cookie value when set in the initial request, and sent in subsequent responses where withCredentials: true)

Notice the difference between "path" and "site" for Cookie purposes. "path" is not security-related; "site" is security-related:

path

Servers can set a Path attribute in the Set-Cookie, but it doesn't seem security related:

Note that path was intended for performance, not security. Web pages having the same origin still can access cookie via document.cookie even though the paths are mismatched.

site

The SameSite attribute, according to example.dev article, can restrict or allow cross-site cookies; but what is a "site"?

It's helpful to understand exactly what 'site' means here. The site is the combination of the domain suffix and the part of the domain just before it. For example, the www.example.dev domain is part of the example.dev site...

This means a request to static.example.dev from www.example.dev, is a sameSite request (the only difference in the URLs is in the subdomains).

The public suffix list defines this, so it's not just top-level domains like .com but also includes services like github.io

This means a request to your-project.github.io from my-project.github.io, is a a cross-site request (these URLs are at different domains, because github.io is the domain suffix; the domains your-project vs my-project are different; hence different sites)

This means what's to the left of the public suffix; is the subdomain (but the subdomain is a part of the host; see the BONUS reply in this answer)

• www is the subdomain in www.example.dev; same site as static.example.dev
• your-project is the domain in your-project.github.io; separate site as my-project.github.io

In this URL https://www.example.com:8888/examples/index.html, remember these parts:

• the "protocol": https://
  • the "scheme": https
• the "port": 8888
• the "domain name" aka location.hostname: www.example.com
  • the "domain suffix" aka "top-level domain" (TLD): com
  • the "domain": example
  • the "subdomain": www (the subdomain could be single-level (like www) or multi-level (like foo.bar in foo.bar.example.com)
• the "site" (as in "cross-site" if another URL had a different "site" value): example.com
  • "site" = "domain" + "domain suffix" = example.com
• the "path": /examples/index.html

Useful links:

• Anatomy of a URL
• Same-Origin cookie policy and URL anatomy
• SameSite cookies explained
• Secure cross-domain cookies for HTTP | Journal of Internet Services and Applications | Full Text
• draft-ietf-httpbis-rfc6265bis-03
• Web Security 1: Same-Origin and Cookie Policy
• Set-Cookie - HTTP | MDN

(Be careful; I was testing my feature in Chrome Incognito tab; according to my chrome://settings/cookies; my settings were "Block third party cookies in Incognito", so I can't test Cross-site cookies in Incognito.)

I've created an NPM module, which allows you to share locally-stored data across domains: https://www.npmjs.com/package/cookie-toss

By using an iframe hosted on Domain A, you can store all of your user data on Domain A, and reference that data by posting requests to the Domain A iframe.

Thus, Domains B, C, etc. can inject the iframe and post requests to it to store and access the desired data. Domain A becomes the hub for all shared data.

With a domain whitelist inside of Domain A, you can ensure only your dependent sites can access the data on Domain A.

The trick is to have the code inside of the iframe on Domain A which is able to recognize which data is being requested. The README in the above NPM module goes more in depth into the procedure.

Hope this helps!

Along with @Ludovic(approved answer) answers we need to check one more option when getting set-cookies header,

set-cookie: SESSIONID=60B2E91C53B976B444144063; Path=/dev/api/abc; HttpOnly

Check for Path attribute value also. This should be the same as your API starting context path like below

https://www.example.com/dev/api/abc/v1/users/123

or use below value when not sure about context path

Path=/;

Since it is difficult to do 3rd party cookies and also some browsers won't allow that.

You can try storing them in HTML5 local storage and then sending them with every request from your front end app.