Login🌙

Cookies

Before diving into Cookie-based authentication, let's briefly describe what Cookies are.

A Cookie is a bit of information that is stored inside the browser. Each Cookie has a name and a value, the latter has a size limit of 4kb.

While you can set Cookies on the browser via JavaScript…

document.cookie = 'foo=bar';

…most of the times Cookies are set by a server inside the header of a response:

Set-Cookie: foo=bar

Cookies can be set by the server both with navigation requests and asynchronous requests.

Once a Cookie is set, it is bound to the domain that created it and its scheme (http or https). But what does it mean?

When the browser makes a request, it automatically collects all the Cookies that are bound to the destination domain (and schema) and appends them to the request via the Cookie header, like so:

Cookie: foo=bar;

This means that Cookies created by a.com are never sent to b.com. This makes Cookies a great option to store session identifiers on someone's browser in order to keep them authenticated in a website for long periods of time.

Third-party Cookies

Say you're visiting a.com and the website makes an asynchronous request to another domain, b.com. What if the response of that request sets a Cookie? That Cookie will be bound to b.com, because that's the domain which created it.

From the perspective of a.com, that Cookie is a Third-party Cookie. The website cannot see it or touch it, and if a request to a server on a.com is made, that Cookie is never sent. It'll only be sent for requests to b.com. This is the type of mechanism usually adopted by tracking tools such as analytics and social networks.

Example: tracking cookies

When you login, facebook.com adds a Cookie to your browser. Then, you visit amazon.com on the same browser, and you open a product page. If amazon.com has the Facebook Pixel (its tracking mechanism) enabled, it will send an asynchronous request to facebook.com saying "This person is interested in this product". Facebook will know who you are because that request will contain the Cookie that facebook.com set previously on your browser. But amazon.com has no way of knowing who you are, because they can't see that Cookie.

But we're talking about authentication, and for that First-party Cookies are the norm, where no third-party domain is involved.

Attributes

A Cookie can have attributes (or flags), in order to tell the browser how to treat it more specifically.

  • Expires: specifies an expiration date.
  • Max-Age: specifies a maximum validity time. It has precedence over "Expires".s
Permanent Cookies

If either "Expires" or "Max-Age" are present, we talk about a Permanent Cookie. It's not called "permanent" because it never expires, but because it survives even if the user closes the browser. Otherwise, we talk about a Session Cookie, which is discarded when the browser is closed. Permanent Cookies are much more common.

  • Domain: the Cookie is saved by the browser only if the domain matches.
    • Without the attribute, the domain is the one that created the Cookie, without sub-domains.
    • With the attribute, sub-domains are allowed.
  • Path: the Cookie is sent only if the request path matches.
    • Sub-directories are included, eg. a path /api allows /api/users.
  • Secure: the Cookie is only sent over https, with the exception of localhost. It helps with "Man in the middle" attacks.
  • HttpOnly: the Cookie is not accessible by JavaScript on the browser. It helps with "XSS" attacks. Only a server can set this attribute.
  • SameSite: tells the browser whether to send the Cookie in third-party requests. It helps with CSRF attacks, which we'll talk about later. It can be set to:
    • Strict: the Cookie is never sent with cross-site requests. This may be a good default for very delicate environments, such as banks.
    • Lax (default in modern browsers): the Cookie is not sent for mutating requests (eg. POST), but it's sent for navigation requests (eg. navigating to a link).
    • None: the Cookie is always sent. Requires the "Secure" attribute, and requires additional checks by the developer, such as CSRF Tokens.

While some of these are purely optional (eg. Domain, Path), Cookie-based Authentication requires for security purposes these 3 attributes:

  • Secure
  • HttpOnly
  • SameSite set to "Lax" or "Strict"

So, from now on, whenever we talk about Authentication Cookies we'll be referring to cookies with these attributes.

On top of that, either Expires or Max-Age are usually set, so that the user doesn't have to enter the credentials every time they open the browser. It's time to see how all of this works.

Authentication Cookies are always set by the server.