Témoins de l’Authentication API
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.