Skip to main content
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 lui renvoie la même chaîne 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. C’est pourquoi Auth0 a apporté les changements suivants à sa gestion des cookies :
  • Les cookies pour lesquels l’attribut samesite n’est pas défini seront définis sur lax.
  • Les cookies avec sameSite=none doivent être marqués comme sécurisés, sinon ils ne peuvent pas être enregistrés dans l’espace de stockage des 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’on ne leur demande pas de se connecter de nouveau 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 dans un mélange de ces technologies) profitent davantage d’une authentification basée sur des jetons. Les applications Web traditionnelles côté serveur, quant à elles, ont traditionnellement recours à une authentification basée sur les cookies. L’authentification basée sur les cookies est mise en œuvre différemment selon les plateformes Web, mais au bout du compte, elles finissent toutes par créer un cookie (associé à 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 espace de stockage (en mémoire s’il s’agit d’un seul serveur, ou dans un stockage persistant s’il s’agit d’une batterie 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 dans .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 ou sans état.

​
Cookies avec état

Les cookies avec état contiennent un pointeur vers un enregistrement dans la 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 faire des appels à la base de données pour lire la session (et parfois l’écrire) à chaque requête HTTP effectuée par un utilisateur.
  • Peuvent être difficiles à faire évoluer lorsque vous avez beaucoup d’utilisateurs et, par conséquent, de nombreuses opérations de lecture/écriture dans votre base de données.

​
Cookies sans état

Les cookies sans état sont autonomes; ils contiennent toute l’information de session nécessaire (pour les utilisateurs authentifiés, l’ID utilisateur) et sont stockés côté client. Pour prévenir toute altération externe, les cookies sans état doivent être chiffrés (ou à tout le 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’effectuer de requête à une base de données.
  • Faciles à faire évoluer.
Inconvénients :
  • Il faut limiter l’information de session stockée, car la taille des cookies est limitée (max. 4 KB dans la plupart des navigateurs). Même si l’information de session peut être répartie 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 qu’ils possèdent tous la clé permettant de chiffrer/déchiffrer ou de signer le cookie.

​
En savoir plus