Passer au contenu principal
Les cookies sont des chaînes de données qu’un serveur Web envoie au navigateur. Lorsqu’un navigateur envoie une requête ultérieure au serveur Web, il renvoie la même chaîne au serveur Web avec sa requête.
Auparavant, dans Auth0, les options de l’attribut de cookie samesite étaient true, false, strict ou lax. Si vous ne définissiez pas l’attribut manuellement, Auth0 utilisait la valeur par défaut false. À compter de février 2020, Google Chrome v80 a modifié la façon dont il gère les cookies. Auth0 a donc apporté les changements suivants à sa gestion des cookies :
  • Les cookies sans attribut samesite seront définis sur lax.
  • Les cookies avec sameSite=none doivent être sécurisés; sinon, ils ne peuvent pas être enregistrés dans le stockage de cookies du navigateur.
L’objectif de ces changements est d’améliorer la sécurité et d’aider à atténuer les attaques CSRF.
Les sites Web utilisent généralement des cookies pour s’assurer que les utilisateurs sont reconnus lorsqu’ils passent d’une page à l’autre, afin qu’ils n’aient pas à se reconnecter chaque fois. Les sites Web utilisent aussi des cookies pour mémoriser les renseignements saisis par les utilisateurs. Par exemple, les sites de commerce électronique utilisent des cookies pour mémoriser les articles placés dans un panier d’achat. Les utilisateurs peuvent choisir d’accepter ou non les cookies en modifiant les paramètres de leur navigateur. En règle générale, les applications monopage (comme React, Vue et AngularJS + Node), les applications mobiles natives (comme iOS et Android) et les API Web (écrites en Node, Ruby, ASP.NET, ou avec une combinaison de ces technologies) se prêtent généralement mieux à l’authentification basée sur les jetons. Les applications Web traditionnelles côté serveur, quant à elles, utilisent habituellement l’authentification basée sur les cookies. L’authentification basée sur les cookies est implémentée différemment selon les plateformes Web, mais en fin de compte, elles finissent toutes par définir un cookie (lié à une session sur le serveur) qui représente l’utilisateur authentifié. À chaque requête, ce cookie est envoyé et la session est désérialisée à partir d’un stockage (en mémoire s’il s’agit d’un seul serveur, ou dans un stockage persistant s’il s’agit d’une grappe de serveurs). Nous fournissons des SDK pour la plupart des plateformes, qui s’intègrent au sous-système d’authentification correspondant (comme passport sur Node, IPrincipal sur .NET ou Java, etc.). Lorsque vous créez une application qui nécessite une authentification, vous pouvez utiliser des sessions et des cookies pour déterminer si un utilisateur est authentifié chaque fois qu’une requête est effectuée. Pour ce faire, vous pouvez choisir d’utiliser des cookies avec état ou sans état.

​
Cookies avec état

Les cookies avec état contiennent un pointeur vers un enregistrement de base de données où sont stockées les informations de session. Avantages :
  • N’ont aucune limite quant à la quantité d’informations de session pouvant être stockées.
  • Permettent d’effacer facilement la session d’un utilisateur : il suffit de supprimer l’enregistrement de la base de données.
Inconvénients :
  • Nécessitent une base de données pour stocker les données de session (mais la plupart des applications web en ont déjà une).
  • Augmentent la latence, puisqu’il faut effectuer des appels à la base de données pour lire la session (et parfois l’écrire) pour chaque requête HTTP faite par un utilisateur.
  • Peuvent être difficiles à faire évoluer lorsque vous avez beaucoup d’utilisateurs et, par conséquent, de nombreuses opérations de lecture et d’écriture dans votre base de données.

​
Cookies sans état

Les cookies sans état sont autonomes; ils contiennent toutes les informations de session nécessaires (pour les utilisateurs authentifiés, l’identifiant de l’utilisateur) et sont stockés côté client. Pour empêcher toute falsification externe, les cookies sans état doivent être chiffrés (ou au moins signés). Avantages :
  • Peuvent être mis en œuvre facilement; ne nécessitent pas de backend particulier.
  • Réduisent la latence, car il n’est pas nécessaire d’interroger une base de données.
  • Faciles à faire évoluer.
Inconvénients :
  • Il faut limiter les informations de session stockées, car la taille des cookies est limitée (4 Ko max. dans la plupart des navigateurs). Même s’il est possible de répartir les informations de session entre plusieurs cookies, nous ne le recommandons pas.
  • Il est difficile de révoquer une session, puisqu’il n’existe aucun enregistrement dans une base de données à supprimer; vous devrez trouver d’autres moyens de forcer l’effacement d’une session.
  • Si vous utilisez plusieurs serveurs Web, vous devez vous assurer que tous les serveurs possèdent la clé nécessaire pour chiffrer/déchiffrer ou signer le cookie.

​
En savoir plus