An HTTP cookie (such as a web cookie or browser cookie) is a very simple dictionary/key-value store that a server can send to the client. It is sent by the server using the Set-Cookie header. For example, a Set-Cookie header may look like this:

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Expires=<date>

Multiple Set-Cookie headers can be sent in the same response message to compose the key-value store.

What's special about cookies is the fact that most browser clients will automatically send this key-value store back with each subsequent request, this time inside a Cookie header:

Cookie: name1=value1; name2=value2

Therefore, if we use a cookie to store the user's session ID in the browser, it'll allow the server to determine whether the request comes from the same client, because it will have the same session ID in the cookie.

The Domain directive of the cookie determines which domain (or subdomain) the client will set the Cookie header for. For instance, a cookie set by abc.xyz would only be sent back by the client for requests to abc.xyz, but not if the request is going to foo.bar.

Although cookies sound like a great idea, there are many disadvantages of using cookies, especially if we are dealing with cross-domain and CORS. Because cookies only work for that domain (or its subdomains), they are unable to authenticate with a related service if it is under a different domain. For example, when our platform expands from a simple user directory (deployed at hobnob.social) to, say, a event organization application (hobnob.events), and we want to let users who have logged in to hobnob.social also be automatically logged in to hobnob.events; this cannot be done using cookies as the cookies are set by a different domain.

Cookies are also more convenient only for browsers; having to manage cookies for non-browser clients is more of a hassle.

Furthermore, cookies are also vulnerable to Cross-Site Scripting (XSS) and Cross-Site Request Forgery (XSRF) attacks.