> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> 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.
# Modifications de l’attribut de cookie SameSite
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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-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](https://www.chromium.org/updates/same-site/incompatible-clients).
* 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`