> ## 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 témoin SameSite, affectent vos applications web qui intègrent du contenu provenant de domaines tiers.
# Changements apportés à l’attribut de témoin SameSite
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](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 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](https://www.chromium.org/updates/same-site/incompatible-clients).
* 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`