Modifications des attributs du témoin SameSite

Décrit comment les modifications apportées au navigateur, telles que 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 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 SAML 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 :

Attribut	Description
strict	Envoyer le témoin si l’utilisateur navigue dans les limites d’origine du site
lax	Envoyer le témoin si l’utilisateur navigue entre les domaines, mais pas pour des contextes tiers (iframes ou posts)
none	Envoyer le témoin avec les demandes qui traversent les limites d’origine du site Web. À moins que d’autres conditions soient présentes (c.-à-d., les témoins tiers sont bloqués), n’envoyez pas le témoin.

Voici quelques-uns des attributs de témoin qui vous sont peut-être familiers :

Attribut	Description
httpOnly	Permet à un témoin d’être envoyé uniquement avec des requêtes HTTP ; non lisible en utilisant le document.cookie de Javascript
secure	Permet au navigateur d’envoyer le témoin uniquement à un contexte sécurisé ; que le contexte soit considéré comme sécurisé ou non dépend du navigateur, mais cela nécessite généralement l’utilisation de HTTPS
max-age / expires	Contrôle si le témoin est un témoin de session (i.e., jeté lorsque votre navigateur clos la session) ou persistant (i.e., le témoin persiste au-delà de la session du navigateur)

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.

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.

​

Caractéristiques affectées

Le tableau ci-dessous montre comment les modifications de l’attribut SameSite peut affecter vos applications.

Comportement de l’application	Affecté par le changement
Fichiers témoins définis comme sameSite=none lorsque le site Web n’est pas https://	Oui
Les fichiers témoins n’ont pas de valeur d’attribut sameSite explicite définie et sont requis dans un contexte d’origine croisée (tel que HTTP form_post, intégration d’un iframe)	Oui
Applications natives (tout ce qui n’est pas basé sur des fichiers témoins + basé sur le Web)	Non (M2M)
Sous-domaine différent sur le même eTLD+1 (l’application est sur le même eTLD+1 que le locataire Auth0 du domaine personnalisé)	Potentiellement

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.