Saltar al contenido principal
Las cookies son cadenas de datos que un servidor web envía al navegador. Cuando un navegador envía una solicitud posterior al servidor web, envía esa misma cadena al servidor web junto con la solicitud.
Anteriormente, en Auth0, las opciones del atributo de cookie samesite eran true, false, strict o lax. Si no configuraba el atributo manualmente, Auth0 usaba el valor predeterminado false. A partir de febrero de 2020, Google Chrome v80 cambió la forma en que gestiona las cookies. En consecuencia, Auth0 implementó los siguientes cambios en la forma en que gestiona las cookies:
  • Las cookies sin el atributo samesite configurado pasarán a establecerse como lax.
  • Las cookies con sameSite=none deben ser seguras; de lo contrario, no se pueden guardar en el almacenamiento de cookies del navegador.
El objetivo de estos cambios es mejorar la seguridad y ayudar a mitigar ataques CSRF.
Los sitios web suelen usar cookies para garantizar que se reconozca a los usuarios cuando navegan entre páginas, de modo que no se les pida volver a iniciar sesión cada vez. Los sitios web también usan cookies para recordar información que los usuarios han introducido. Por ejemplo, los sitios de comercio electrónico usan cookies para recordar los artículos añadidos a un carrito de compra. Los usuarios pueden elegir si aceptan cookies cambiando la configuración de su navegador. Por lo general, las aplicaciones de una sola página (como React, Vue y AngularJS + Node), las aplicaciones móviles nativas (como iOS y Android) y las API web (escritas en Node, Ruby, ASP.NET o una combinación de estos) son las que más se benefician de la autenticación basada en tokens. Tradicionalmente, las aplicaciones web del lado del servidor han utilizado la autenticación basada en cookies. La autenticación basada en cookies se implementa de forma diferente en cada plataforma web, pero, en definitiva, todas terminan estableciendo una cookie (vinculada a una sesión en el servidor) que representa al usuario autenticado. En cada solicitud, esa cookie se envía y la sesión se deserializa desde algún almacén (en memoria si se trata de un solo servidor o en algún almacenamiento persistente si es una granja de servidores). Proporcionamos SDK para la mayoría de las plataformas que se integran con el subsistema de autenticación correspondiente (como passport en Node, IPrincipal en .NET o Java, etc.). Cuando desarrolla una aplicación que requiere autenticación, puede usar sesiones y cookies para determinar si un usuario está autenticado cada vez que se realiza una solicitud. Para ello, puede optar por usar cookies con estado o sin estado.

​
Cookies con estado

Las cookies con estado contienen una referencia a un registro de base de datos que almacena la información de la sesión. Ventajas:
  • No tienen limitaciones en cuanto a la cantidad de información de sesión que se puede almacenar.
  • Permiten borrar fácilmente la sesión de un usuario: basta con eliminar el registro de la base de datos.
Desventajas:
  • Requieren una base de datos para almacenar los datos de la sesión (aunque la mayoría de las aplicaciones web ya cuentan con una).
  • Aumentan la latencia, ya que hay que hacer llamadas a la base de datos para leer la sesión (y, a veces, escribirla) en cada solicitud HTTP que hace un usuario.
  • Pueden ser difíciles de escalar cuando hay muchos usuarios y, por lo tanto, muchas operaciones de lectura y escritura en la base de datos.

​
Cookies sin estado

Las cookies sin estado son autocontenidas: incluyen toda la información de sesión necesaria (para los usuarios autenticados, el ID de usuario) y se almacenan en el cliente. Para evitar manipulaciones externas, las cookies sin estado deben cifrarse (o, al menos, firmarse). Ventajas:
  • Se pueden implementar fácilmente; no requieren un backend especial.
  • Reducen la latencia porque no es necesario consultar una base de datos.
  • Son fáciles de escalar.
Desventajas:
  • Debe limitarse la información de sesión almacenada, porque las cookies tienen un tamaño limitado (máximo 4 KB en la mayoría de los navegadores). Aunque la información de sesión puede dividirse entre varias cookies, no lo recomendamos.
  • Dificultan la revocación de una sesión, porque no hay ningún registro en una base de datos que se pueda eliminar; tendrá que encontrar otros métodos para borrar una sesión por la fuerza.
  • Si usa varios servidores web, debe asegurarse de que todos los servidores tengan la clave para cifrar/descifrar o firmar la cookie.

​
Más información