Cookies are strings of data that a web server sends to the browser. When a browser sends a future request to the web server, it sends the same string to the web server along with its request.
Previously in Auth0, the samesite cookie attribute options were true, false, strict or lax. If you didn’t set the attribute manually, Auth0 would use the default value of false. Effective February 2020, Google Chrome v80 changed the way it handles cookies. To that end, Auth0 implemented the following changes to how it handles cookies:
  • Cookies without the samesite attribute set will be set to lax.
  • Cookies with sameSite=none must be secured, otherwise they cannot be saved in the browser’s cookie jar.
The goal of these changes are to improve security and help mitigate CSRF attacks.
Websites typically use cookies to ensure that users are recognized when they move between pages, so they don’t get asked to log in again every time. Websites also use cookies to remember information users have entered. For example, e-commerce sites use cookies to remember the items placed in a shopping cart. Users can choose whether to accept cookies by changing the settings in their browser. Typically, single-page apps (such as React, Vue, and AngularJS + Node), native mobile apps (such as iOS and Android), and web APIs (written in Node, Ruby, ASP.NET, or a mix of those) benefit most from token-based authentication. Traditional, server-side web applications have traditionally used cookie-based authentication. Cookie-based authentication is implemented by each web platform differently, but at the end of the day, they all end up setting some cookie (tied to a session on the server) which represents the authenticated user. On each request, that cookie is sent and the session is deserialized from some store (in memory if it’s a single server or some persistent storage if it’s a server farm). We provide SDKs for most of the platforms that will tie into the corresponding authentication subsystem (such as passport on node, IPrincipal on .NET or Java, and so on). When you build an application that requires authentication, you can use sessions and cookies to determine if a user is authenticated each time a request is made. To do this, you can choose to use either stateful or stateless cookies.

​
Stateful cookies

Stateful cookies contain a pointer to a database record that stores the session information. Pros:
  • Have no limitations on amount of session information stored.
  • Can easily clear a user’s session—just remove the record from the database.
Cons:
  • Requires a database to store the session data (but most web applications already have this).
  • Increases latency because you have to make database calls to read the session (and sometimes write it) for each HTTP request a user makes.
  • Can be challenging to scale when you have many users and therefore many reads/writes to your database.

​
Stateless cookies

Stateless cookies are self-contained; they include all session information that you need (for authenticated users, the user ID) and reside on the client. To prevent external tampering, stateless cookies should be encrypted (or at least signed). Pros:
  • Can implement easily; doesn’t require a special backend.
  • Reduces latency because you don’t have to call a database.
  • Easy to scale.
Cons:
  • Must restrict stored session information because cookies are limited in size (max 4KB in most browsers). Although session information may be split between multiple cookies, we don’t recommend it.
  • Makes it difficult to revoke a session, because there is no record in a database you can delete; you’ll need to find other methods to forcefully clear a session.
  • If using multiple web servers, must make sure all servers have the key to encrypt/decrypt or sign the cookie.

​
Learn more