Témoins de l’API d’authentification

Découvrez les témoins de l’API d’authentification, notamment ce qu’ils sont, à quoi ils servent et comment les gérer.

L’API d’authentification d’Auth0 utilise un ensemble de témoins HTTP pour prendre en charge l’authentification unique (SSO), l’authentification multifacteur (MFA) et la protection contre les attaques. 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.
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.

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.

​

Témoins et domaines personnalisés

Si vous utilisez des domaines personnalisés, 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 Auth0 Dashboard. 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 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 domaines personnalisés, consultez Sending Cookies to the Origin Server.

​

En savoir plus

• Modifications apportées à l’attribut SameSite des cookies
• Vérifier le domaine
• Résoudre les problèmes liés à l’authentification multifacteur (MFA)