Témoins

Les témoins sont des chaînes de données qu’un serveur Web envoie au navigateur. Lorsqu’un navigateur envoie une nouvelle requête au serveur Web, il envoie la même chaîne de données au serveur Web avec sa requête.

Auparavant, dans Auth0, les options des attributs du témoin samesite étaient true, false, strict ou lax. Si vous ne définissiez pas l’attribut manuellement, Auth0 utilisait la valeur par défaut de false. Depuis février 2020, Google Chrome v80 a modifié la façon dont il gère les témoins. À cette fin, Auth0 a implémenté les changements suivants dans la façon dont il traite les témoins :

Les témoins sans attribut samesite seront définis comme étant lax.
Les témoins ayant un attribut sameSite=none doivent être sécurisés, sinon ils ne peuvent pas être enregistrés dans le groupe de témoins du navigateur.

L’objectif de ces modifications est d’améliorer la sécurité et de réduire les attaques CSRF.

Les sites Web utilisent généralement des témoins pour s’assurer que les utilisateurs sont reconnus lorsqu’ils passent d’une page à une autre, de sorte qu’il ne leur est pas demandé de se reconnecter à chaque fois. Les sites Web utilisent également des témoins pour mémoriser les informations saisies par les utilisateurs. Par exemple, les sites de commerce électronique utilisent des témoins pour mémoriser les articles placés dans un panier d’achat.

Les utilisateurs peuvent choisir d’accepter ou non les témoins en modifiant les paramètres de leur navigateur.

Authentification basée sur les témoins

En général, les applications à une page (telles que React, Vue et AngularJS + Node), les applications mobiles natives (telles que iOS et Android) et les API Web (écrites en Node, Ruby, ASP.NET ou une combinaison de ces technologies) bénéficient le plus de l’authentification basée sur des jetons. Les applications Web traditionnelles côté serveur ont généralement eu recours à l’authentification basée sur les témoins.

L’authentification basée sur les témoins est mise en œuvre différemment par chaque plateforme Web, mais en fin de compte, elles finissent toutes par mettre en place un témoin (lié à une session sur le serveur) qui représente l’utilisateur authentifié. À chaque demande, ce témoin est envoyé et la session est désérialisée à partir d’un magasin (en mémoire s’il s’agit d’un serveur unique ou dans un stockage permanent s’il s’agit d’une batterie de serveurs). Nous fournissons des trousses SDK pour la plupart des plateformes qui se connecteront au sous-système d’authentification correspondant (comme passport sur node, IPrincipal sur .NET ou Java, et ainsi de suite).

Lorsque vous créez une application nécessitant une authentification, vous pouvez utiliser des sessions et des témoins pour déterminer si un utilisateur est authentifié à chaque fois qu’une demande est faite. Pour ce faire, vous pouvez choisir d’utiliser des témoins avec ou sans état.

Témoins avec état

Les témoins avec état contiennent un pointeur vers un enregistrement de base de données qui stocke les informations de session.

Avantages :

Ne sont pas limités quant à la quantité d’informations de session stockées.
Il est facile d’effacer la session d’un utilisateur : il suffit de supprimer l’enregistrement de la base de données.

Inconvénients :

Nécessite une base de données pour stocker les données de session (mais la plupart des applications Web en disposent déjà).
Augmente la latence car vous devez faire des appels à la base de données pour lire la session (et parfois l’écrire) pour chaque requête HTTP d’un utilisateur.
Peut être difficile à faire évoluer lorsque vous avez beaucoup d’utilisateurs et donc beaucoup de lectures/écritures dans votre base de données.

Témoins sans état

Les témoins sans état sont autonomes; ils contiennent toutes les informations de session dont vous avez besoin (pour les utilisateurs authentifiés, l’identifiant de l’utilisateur) et résident du côté client. Pour éviter toute altération externe, les témoins sans statut doivent être chiffrés (ou au moins signés).