> ## 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écouvrez les témoins de l’API d’authentification, notamment ce qu’ils sont, à quoi ils servent et comment les gérer.

# Témoins de l’API d’authentification

L’API d’authentification d’Auth0 utilise un ensemble de témoins HTTP pour prendre en charge l’[authentification unique (SSO)](/fr-CA/docs/authenticate/single-sign-on), l’[authentification multifacteur (MFA)](/fr-CA/docs/secure/multi-factor-authentication) et la [protection contre les attaques](/fr-CA/docs/secure/attack-protection). Le tableau ci-dessous présente certains des témoins sur lesquels l’API d’authentification s’appuie et décrit leur utilité :

| **Témoin**          | **Fonctionnalité**             | **Utilité**                                                                                                                           |
| ------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| `auth0`             | Authentification unique        | Utilisé pour mettre en œuvre la [couche de session Auth0](/fr-CA/docs/manage-users/sessions/session-layers).                          |
| `auth0_compat`      | Authentification unique        | Témoin de secours pour l’authentification unique dans les navigateurs qui ne prennent pas en charge l’attribut `sameSite=None`.       |
| `auth0-mf`          | Authentification multifacteur  | Utilisé pour établir le niveau de confiance d’un appareil donné.                                                                      |
| `auth0-mf_compat`   | Authentification multifacteur  | Témoin de secours pour l’authentification multifacteur dans les navigateurs qui ne prennent pas en charge l’attribut `sameSite=None`. |
| `a0_users:sess`     | Connexion classique            | Utilisé pour la protection contre les attaques CSRF dans les flux de connexion classique.                                             |
| `a0_users:sess.sig` | Connexion classique            | Utilisé pour la protection contre les attaques CSRF dans les flux de connexion classique.                                             |
| `did`               | Protection contre les attaques | Identification de l’appareil pour la protection contre les attaques.                                                                  |
| `did_compat`        | Protection contre les attaques | Témoin de secours pour la détection des anomalies dans les navigateurs qui ne prennent pas en charge l’attribut `sameSite=None`.      |

<Warning>
  Auth0 ne prend pas en charge les scénarios dans lesquels les témoins d’authentification mentionnés sont modifiés de quelque manière que ce soit, notamment par l’ajout, la modification ou la suppression d’attributs de témoins, que ce soit au moyen de navigateurs non standards, d’extensions de navigateur ou de proxys HTTP.
</Warning>

<div id="cookies-and-custom-domains">
  ## Témoins et domaines personnalisés
</div>

Si vous utilisez des [domaines personnalisés](/fr-CA/docs/customize/custom-domains), les témoins de l’API d’authentification sont envoyés au nom d’hôte personnalisé, ou CNAME, que vous avez configuré dans le <Tooltip tip="Auth0 Dashboard : produit principal d’Auth0 pour configurer vos services." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip>. L’attribut de domaine de chaque témoin, qui indique le domaine pour lequel le témoin est valide, est défini dans l’en-tête de requête du témoin et doit correspondre à cet attribut de domaine.

Si aucun domaine n’est précisé, l’attribut de domaine prend par défaut la valeur de l’hôte de la requête. Si vous utilisez la spécification [HTTP State Management Mechanism](https://datatracker.ietf.org/doc/html/rfc2109#section-2) de l’IETF pour définir des témoins sur le domaine parent, le témoin sera partagé avec tous les sous-domaines du domaine parent.

Par exemple, vous définissez votre CNAME sur `login.example_domain.com` comme sous-domaine de `example_domain.com`. Vous hébergez d’autres applications sous le domaine parent, comme `app1.example_domain.com` et `app2.example_domain.com`. Lorsque les utilisateurs visitent `login.example_domain.com`, les témoins de `app1.example_domain.com` et `app2.example_domain.com` peuvent être envoyés avec les requêtes à l’API d’authentification d’Auth0.

Pour protéger notre plateforme, et parce que ces témoins peuvent prendre une taille considérable et être partagés avec d’autres sous-domaines, Auth0 peut rejeter les requêtes dont les en-têtes sont excessivement volumineux (plusieurs kilo-octets). Les applications doivent être conçues de manière à ne pas envoyer de témoins excessivement volumineux à l’API d’authentification d’Auth0. Pour en savoir plus sur le comportement des témoins avec les <Tooltip tip="Domaine personnalisé : domaine tiers portant un nom spécialisé ou distinctif." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=custom+domains">domaines personnalisés</Tooltip>, consultez [Sending Cookies to the Origin Server](https://datatracker.ietf.org/doc/html/rfc2109#section-4.3.4).

<div id="learn-more">
  ## En savoir plus
</div>

* [Modifications apportées à l’attribut SameSite des témoins](/fr-CA/docs/manage-users/cookies/samesite-cookie-attribute-changes)