Témoins de l’Authentication API

Découvrez les témoins de l’Authentication API, notamment ce qu’ils sont, à quoi ils servent et comment il faut les traiter.

Authentication API Auth0 utilise un ensemble de témoins HTTP pour activer l’authentification unique (SSO), l’authentification multifacteur (MFA) et les capacités de protection contre les attaques. Le tableau ci-dessous présente certains des témoins sur lesquels s’appuie l’Authentication API et décrit leurs objectifs :

Témoin	_Fonctionnalité	Objet
auth0	Authentification unique	Utilisé pour implémenter la couche de session Auth0.
auth0_compat	Authentification unique	Témoin de repli pour l’authentification unique sur les navigateurs qui ne prennent pas en charge l’attribut sameSite=None.
auth0-mf	Authentification multifacteur (MFA)	Utilisé pour établir le niveau de confiance pour un périphérique donné.
auth0-mf_compat	Authentification multifacteur (MFA)	Témoin de repli pour l’authentification multifacteur (MFA) sur les navigateurs qui ne prennent pas en charge l’attribut sameSite=None.
a0_users:sess	Connexion classique	Utilisé pour la protection CSRF dans les flux de connexion classique.
a0_users:sess.sig	Connexion classique	Utilisé pour la protection 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 repli pour la détection d’anomalies sur 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, y compris l’ajout, la modification ou la suppression d’attributs de témoins, que ce soit par l’intermédiaire de navigateurs non standard, de modules complémentaires de navigateurs ou de serveurs mandataires HTTP.

​

Témoins et domaines personnalisés

Si vous utilisez des domaines personnalisés, les témoins d’Authentication API sont envoyés au nom d’hôte personnalisé ou CNAME que vous avez configuré dans Auth0 Dashboard. L’attribut de domaine de chaque témoin, qui précise le domaine pour lequel le témoin est valide, est défini dans l’en-tête de la demande de témoin. Il correspond au domaine avec l’attribut de domaine.

Si aucun domaine n’est précisé, l’attribut de domaine par défaut est l’hôte de la demande. Si vous utilisez les spécifications Mécanisme de gestion de l’état HTTP 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, telles que app1.example_domaine.com et app2.example_domaine.com. Lorsque les utilisateurs visitent login.example_domaine.com, les témoins de app1.example_domaine.com et app2.example_domaine.com peuvent être envoyés avec des requêtes à l’Authentication API Auth0.

Pour protéger notre plateforme et parce que ces témoins peuvent atteindre une taille considérable et être partagés avec d’autres sous-domaines, Auth0 peut rejeter les requêtes comportant des en-têtes excessivement volumineux (plusieurs kilo-octets). Les applications doivent être conçues de manière à ce que les témoins trop volumineux ne soient pas envoyés à l’Authentication API Auth0. Pour en savoir plus sur le comportement des témoins avec les domaines personnalisés, veuillez consulter Envoyer des témoins au serveur d’origine.

​

En savoir plus

• Modifications des attributs du témoin SameSite
• Vérifier un domaine
• Dépannage des problèmes d’authentification multifacteur (MFA)