Changements apportés à l’attribut de témoin SameSite

Décrit comment les changements apportés aux navigateurs, comme l’attribut de témoin SameSite, affectent vos applications web qui intègrent du contenu provenant de domaines tiers.

Les témoins, qui sont utilisés pour l’authentification et la gestion des sessions, peuvent être sécurisés en définissant des attributs. Auth0 utilise des témoins pour les éléments suivants :

• OIDC Enterprise avec form_post
• SAML liaison HTTP-POST
• message web (aussi appelé checkSession)

​

Attributs SameSite

Vous pouvez ajouter des attributs de témoin SameSite dans l’en-tête de réponse HTTP set-cookie afin de limiter le comportement du navigateur. Cela peut empêcher le navigateur d’envoyer la paire key=value du témoin selon le type d’interaction qui a déclenché la requête HTTP.

Les valeurs d’attribut acceptées sont les suivantes :

Attribut	Description
strict	Envoie le témoin si l’utilisateur navigue à l’intérieur des limites de l’origine du site Web
lax	Envoie le témoin si l’utilisateur navigue entre des domaines, mais pas dans des contextes tiers (iframes ou requêtes POST)
none	Envoie le témoin avec des requêtes qui dépassent les limites de l’origine du site Web. Sauf si d’autres conditions s’appliquent (p. ex., les témoins tiers sont bloqués), le témoin n’est pas envoyé.

Voici certains attributs de témoin que vous connaissez peut-être :

Attribut	Description
httpOnly	Permet d’envoyer un témoin uniquement avec des requêtes HTTP; il n’est pas accessible au moyen de document.cookie en JavaScript
secure	Permet au navigateur d’envoyer le témoin uniquement dans un contexte sécurisé; le fait qu’un contexte soit considéré comme sécurisé ou non dépend du navigateur, mais cela exige généralement l’utilisation de HTTPS
max-age / expires	Détermine si le témoin est un témoin de session (p. ex., supprimé lorsque votre navigateur met fin à sa session) ou persistant (p. ex., le témoin persiste au-delà de la session du navigateur)

À la réception, le navigateur analyse les en-têtes et met à jour son stockage de témoins en conséquence.

​

Modifications apportées aux témoins du navigateur

Depuis février 2020, Google Chrome v80 a modifié la façon dont il gère les témoins. Auth0 a mis en œuvre les changements suivants dans sa gestion des témoins :

• Les témoins pour lesquels l’attribut SameSite n’est pas défini seront réglés sur lax
• Les témoins avec SameSite=none doivent être sécurisés; sinon, ils ne peuvent pas être enregistrés dans le stockage de témoin du navigateur

L’objectif de ces changements est d’améliorer la sécurité et d’aider à atténuer les attaques CSRF.

Ces changements touchent les témoins suivants :

• auth0 (gère les sessions utilisateur)
• auth0-mf (gère les renseignements liés à l’authentification multifacteur)
• did (l’identifiant d’un appareil/agent utilisateur)

Pour ces témoins, Auth0 va :

• Définir l’attribut SameSite sur none, ce qui exige l’utilisation de HTTPS (quel que soit l’environnement)
• Définir des témoins de secours si un navigateur hérité ne prend pas en charge SameSite lorsqu’il est défini sur None. Ces témoins de secours sont auth0_compat, auth0-mf_compat et did_compat

Le schéma ci-dessous montre ce qui se passe lors d’une nouvelle interaction. L’utilisateur final demande une page qu’il n’a jamais visitée auparavant. Le serveur modifie son rendu lorsque le visiteur revient et définit un témoin indiquant que la page a déjà été consultée. La partie grise de l’en-tête set-cookie correspond au témoin réel key=value. La partie rouge correspond aux attributs du témoin que le navigateur stocke dans le stockage de témoin afin de déterminer plus tard s’il doit inclure la paire key+value dans les requêtes.

Le schéma suivant montre ce qui se passe si vous effectuez la même requête dans la même session de navigation. La requête est envoyée au même serveur et, comme les attributs du témoin n’empêchent pas l’envoi du témoin indiquant que la page a déjà été consultée, celui-ci est automatiquement inclus dans la requête sous forme d’en-tête de témoin. Le serveur répondra alors différemment parce qu’il a reçu ce témoin.

​

Fonctionnalités concernées

Le tableau ci-dessous montre comment les changements apportés à l’attribut SameSite peuvent affecter vos applications.

Comportement de l’application	Touché par le changement
Témoins définis avec sameSite=none lorsque le site Web n’est pas en https://	Oui
Les témoins n’ont pas de valeur explicite définie pour l’attribut sameSite et sont requis dans un contexte inter-origine (comme HTTP form_post ou l’intégration d’un iframe)	Oui
Applications natives (tout ce qui n’est pas basé sur les témoins et le Web)	Non (M2M)
Une valeur explicite est déjà définie pour l’attribut de témoin sameSite	Non
Sous-domaine différent sur le même eTLD+1 (l’application se trouve sur le même eTLD+1 que le domaine personnalisé du locataire Auth0)	Potentiellement

Si vous utilisez une application Web avec des sessions (par ex. pour enregistrer les préférences des utilisateurs, les paniers d’achat, etc.) et que vous permettez aux utilisateurs de se connecter à l’aide de fournisseurs d’identité comme Google, GitHub ou Auth0, vous dépendez des témoins pour offrir cette fonctionnalité. Des changements au comportement des témoins dans les navigateurs peuvent nuire à l’expérience utilisateur. Google Chrome, par exemple, est le premier éditeur de navigateur à déployer un changement 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 les cas où SameSite n’est pas défini ont changé : la valeur par défaut de SameSite est passée de none à lax.

Par exemple, supposons que vous créez une nouvelle interface utilisateur et que vous avez plusieurs services que vous acheminez via une passerelle Auth0. À cette passerelle, vous créez une session par témoin. Si vous faites une requête inter-origine, vous pourriez voir cet avertissement dans la console JavaScript :

Un cookie associé à une ressource intersite (URL) a été défini sans l’attribut SameSite. Une future version de Chrome n’enverra les cookies avec des requêtes intersites que s’ils sont définis avec SameSite=None et Secure. Vous pouvez examiner les cookies dans les outils de développement sous Application>Storage>Cookies et voir plus de détails à https://www.chromestatus.com/feature/5088147346030592 et 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.
• Configurer votre application pour qu’elle utilise SameSite=none si elle utilise response_mode=form_post lorsqu’elle interagit avec Auth0 (notez que Chrome ne fait 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 URL de rappel, elles cesseront de fonctionner si vous utilisez de tels témoins pour lier le state de la requête d’autorisation/nonce. Vous devez donc soit utiliser HTTPS, soit définir SameSite=lax