Passer au contenu principal
Les témoins, qui sont utilisés pour l’authentification et le maintien des sessions, peuvent être sécurisés en définissant des attributs. Auth0 utilise des témoins dans les cas suivants :
  • OIDC Enterprise avec form_post
  • Liaison HTTP-POST
  • Message Web (appelé également checkSession)

​
Attributs SameSite

You can add SameSite cookie attributes in the set-cookie HTTP response header to restricts browser behavior. It may prevent the browser from sending the cookie’s key=value pair based on the type of interaction that triggered the HTTP request. Les valeurs d’attribut acceptées sont les suivantes : Voici quelques-uns des attributs de témoin qui vous sont peut-être familiers : Le navigateur, dès réception, analyse les en-têtes et met à jour sa boîte à témoins en conséquence.

​
Modifications des témoins des navigateurs

Depuis février 2020, Google Chrome v80 gère les témoins d’une manière différente. Auth0 a mis en œuvre les changements suivants dans la manière dont les témoins sont traités :
  • La valeur des témoins dont l’attribut SameSite n’a pas été défini sera lax.
  • Cookies with SameSite=none must be secured; otherwise they cannot be saved in the browser’s cookie jar
L’objectif de ces modifications était d’améliorer la sécurité et de réduire les attaques CSRF. Ces modifications concernent les témoins suivants :
  • auth0 (traite les sessions utilisateur)
  • auth0-mf (traite les informations concernant l’authentification multifacteur)
  • did (identifiant d’un appareil/agent utilisateur)
Pour ces témoins, Auth0 :
  • Définira l’attribut SameSite sur none, le témoin exigeant l’utilisation de HTTPS (quel que soit l’environnement).
  • Définira des témoins de secours au cas où un navigateur ancien ne prendrait pas en charge le réglage de SameSite sur None. Ces témoins de secours sont auth0_compat, auth0-mf_compat et did_compat.
L’illustration ci-dessous montre ce qu’il se passe lors d’une nouvelle interaction. L’utilisateur final demande une page qu’il n’a pas encore visitée. Le serveur modifie le rendu de la page lorsque le visiteur revient et met en place un témoin seen. La partie grise de l’en-tête set-cookie est la véritable key=value du témoin. La partie rouge correspond aux attributs du témoin que le navigateur stocke dans la boîte à témoins pour décider ultérieurement s’il doit inclure la paire key+value dans les requêtes.
sameSite Cookie Attributes Fresh Interaction Flow
The following diagram shows what happens if you make the same request using the same browsing session. The request goes to the same server, and because the cookie attributes don’t prohibit the seen cookie to be sent, it is automatically included as a cookie header in the request. The server will now respond differently based on the fact that it received this cookie.
sameSite Cookie Attributes Cookie Return Interaction flow

​
Caractéristiques affectées

Le tableau ci-dessous montre comment les modifications de l’attribut SameSite peut affecter vos applications. Si vous utilisez une application Web avec des sessions (p. ex., pour enregistrer les préférences des utilisateurs, les paniers d’achat,ºetc.), et que vous permettez aux utilisateurs de se connecter en utilisant des fournisseurs d’identité tels que Google, Github, ou Auth0, vous devez utiliser des témoins pour réaliser cette fonctionnalité. Certaines modifications du comportement des témoins dans les navigateurs peuvent perturber l’expérience de l’utilisateur. Google Chrome, par exemple, est le premier navigateur à apporter une modification qui pourrait ne pas être compatible avec votre application Web. Vous remarquerez peut-être que les spécifications de Google Chrome et de Microsoft Edge concernant le réglage de SameSite à un état indéfini ont changé, passant de SameSite à none par défaut, puis à lax. For example, let’s say you build a new UI and have several services that you proxy to via an Auth0 gateway. At this gateway, you create a cookie session. If you make a cross-origin request, you may see this warning in the Javascript console: A cookie associated with a cross-site resource (URL) was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032

​
Mesures à prendre

Pour vous préparer à ce changement, vous devez :
  • Consulter la liste des navigateurs non pris en charge.
  • Définir votre application pour qu’elle utilise SameSite=none si elle utilise response_mode=form_post lors des interactions avec Auth0 (notez que Chrome n’accepte aucune exception, même pour localhost).
  • Définir votre témoin comme sécurisé si son attribut SameSite est égal à None. Sinon, il sera rejeté par le navigateur. Si vous utilisez HTTP pour vos callback URL, celles-ci seront inopérantes si vous utilisez de tels témoins pour lier l’état de la demande d’autorisation état/nombre aléatoire. Par conséquent, vous devez soit utiliser HTTPS, soit définir SameSite=lax.