Modifications de l’attribut de cookie SameSite

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

Les cookies, utilisés pour l’authentification et le maintien des sessions, peuvent être sécurisés en définissant des attributs. Auth0 utilise des cookies 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 cookie SameSite dans l’en-tête de réponse HTTP set-cookie afin de restreindre le comportement du navigateur. Cela peut empêcher le navigateur d’envoyer la paire key=value du cookie 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	Envoyer le cookie si l’utilisateur navigue à l’intérieur du même site d’origine
lax	Envoyer le cookie si l’utilisateur navigue entre des domaines, mais pas dans des contextes tiers (iframes ou publications)
none	Envoyer le cookie avec des requêtes qui dépassent les limites du site d’origine. Sauf si d’autres conditions s’appliquent (par exemple, si les cookies tiers sont bloqués), ne pas envoyer le cookie.

Voici certains attributs de cookie que vous connaissez peut-être :

Attribut	Description
httpOnly	Permet d’envoyer un cookie uniquement avec des requêtes HTTP; il n’est pas accessible au moyen de document.cookie de Javascript
secure	Permet au navigateur d’envoyer le cookie 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 cookie est un cookie de session (p. ex., supprimé lorsque le navigateur met fin à sa session) ou persistant (p. ex., le cookie demeure après la fin de la session du navigateur)

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

​

Modifications apportées aux cookies du navigateur

À compter de février 2020, Google Chrome v80 a modifié la façon dont il gère les cookies. Auth0 a apporté les changements suivants à sa gestion des cookies :

• Les cookies sans attribut SameSite défini seront réglés sur lax
• Les cookies avec SameSite=none doivent être sécurisés; sinon, ils ne peuvent pas être enregistrés dans le stockage de cookies 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 cookies 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 cookies, Auth0 va :

• Définir l’attribut SameSite sur none, le cookie exigeant l’utilisation de HTTPS (peu importe l’environnement)
• Définir des cookies de solution de secours au cas où un navigateur hérité ne prendrait pas en charge la définition de SameSite à None. Ces cookies de solution de secours sont auth0_compat, auth0-mf_compat et did_compat

Le schéma ci-dessous montre ce qui se passe lors d’une première 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 cookie de visite. La partie grise de l’en-tête set-cookie correspond au cookie réel key=value. La partie rouge correspond aux attributs du cookie que le navigateur stocke dans le stockage de cookies afin de décider plus tard s’il doit inclure la paire de cookie key+value dans les requêtes.

Le schéma suivant montre ce qui se passe si vous faites la même requête pendant la même session de navigation. La requête est envoyée au même serveur et, comme les attributs du cookie n’empêchent pas l’envoi du cookie de visite, celui-ci est automatiquement inclus comme en-tête de cookie dans la requête. Le serveur répondra alors différemment, puisqu’il a reçu ce cookie.

​

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
Cookies définis avec sameSite=none lorsque le site Web n’est pas en https://	Oui
Les cookies n’ont pas de valeur d’attribut sameSite explicitement définie et sont requis dans un contexte cross-origin (comme HTTP form_post ou l’intégration d’un iframe)	Oui
Applications Native (tout ce qui n’est ni basé sur les cookies ni sur le Web)	Non (M2M)
Une valeur explicite est déjà définie pour l’attribut de cookie sameSite	Non
Sous-domaine différent sur le même eTLD+1 (l’application se trouve sur le même eTLD+1 que le tenant Auth0 avec 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 à l’aide de fournisseurs d’identité comme Google, Github ou Auth0, vous vous fiez alors aux cookies pour assurer cette fonctionnalité. Certains changements au comportement des cookies 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 pourriez remarquer que, dans Google Chrome et Microsoft Edge, le comportement de SameSite lorsqu’il n’est pas défini est passé d’une valeur par défaut de none à lax.

Par exemple, supposons que vous créiez une nouvelle interface utilisateur et que vous ayez plusieurs services auxquels vous accédez par proxy via une passerelle Auth0. À cette passerelle, vous créez une session par cookie. Si vous faites une requête cross-origin, vous pourriez voir cet avertissement dans la console Javascript :

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 devriez :

• Consulter la liste des navigateurs non pris en charge.
• Configurer votre application pour utiliser 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)
• Marquer votre cookie comme sécurisé si son attribut SameSite est défini à None. Sinon, le navigateur le rejettera. Si vous utilisez HTTP pour vos URL de rappel, elles cesseront de fonctionner si vous utilisez ce type de cookie pour lier le state/le nonce de la demande d’autorisation. Vous devrez donc soit utiliser HTTPS, soit définir SameSite=lax