Passer au contenu principal

Avant de commencer

  • Pour des raisons de sécurité, l’URL d’origine de votre application doit figurer parmi les URL approuvées. Si vous ne l’avez pas déjà ajoutée aux Allowed Callback URLs de votre application, vous devrez l’ajouter à la liste des origines autorisées (CORS).
  • Assurez-vous que Allowed Web Origins dans la vue Settings de votre application est défini sur le domaine qui effectue la requête. Les URL peuvent contenir des caractères génériques pour les sous-domaines, mais elles ne peuvent pas contenir de chemins relatifs après l’URL du domaine. Pour en savoir plus, consultez Espaces réservés pour les sous-domaines.
  • Si vous n’activez pas Domaines personnalisés, vous devrez créer une page de vérification qui utilise Auth0.js comme solution de rechange pour l’authentification inter-origine.
Le partage de ressources entre origines multiples (CORS) est un mécanisme qui permet à une application de charger des données (une ressource) à partir d’un domaine (origine) différent de celui où elle est hébergée. Une stratégie CORS constitue une exception explicite à la politique de même origine, courante dans les applications Web. Par exemple, si vous vouliez que votre application (app.mydomain.com) récupère en arrière-plan une police à partir de Google (fonts.google.com) à l’aide d’Ajax, vous devriez configurer CORS.

​
Configurer l’authentification inter-origine

  1. Accédez à Auth0 Dashboard > Applications > Applications, puis cliquez sur le nom de l’application pour l’ouvrir.
  2. Sous Authentification inter-origine, activez Autoriser l’authentification inter-origine.
  3. Repérez Origines autorisées (CORS), puis saisissez l’URL d’origine de votre application. Pour en savoir plus sur les origines, consultez Origin dans Mozilla MDN Web Docs.
  4. Cliquez sur Save Changes.
Si vous n’avez pas besoin d’utiliser CORS pour votre application, assurez-vous que l’option Autoriser l’authentification inter-origine est désactivée.

​
Créer une page de vérification inter-origine

Il arrive que les témoins tiers ne soient pas disponibles. Certaines versions de navigateur ne prennent pas en charge les témoins tiers et, même lorsqu’elles le font, ceux-ci peuvent être désactivés dans les paramètres de l’utilisateur. Pour les navigateurs pris en charge, vous pouvez utiliser la méthode crossOriginVerification du SDK Auth0.js dans votre application, sur une page dédiée, pour gérer les cas où les témoins tiers sont désactivés. Pour les navigateurs qui ne sont pas pris en charge, comme Chrome, Opera et Safari, l’authentification inter-origine ne fonctionnera pas lorsque les témoins tiers sont désactivés, à moins d’activer les Domaines personnalisés.
La configuration de Safari est libellée « Empêcher le suivi intersite » et utilise Intelligent Tracking Prevention. Malheureusement, cela empêche aussi les témoins tiers d’être utiles dans les scénarios d’authentification. Voici un exemple de l’effet que cela a sur le renouvellement des jetons.
  1. Créez une page dans votre application qui instancie WebAuth à partir de Auth0.js. Appelez immédiatement crossOriginVerification. Vous pouvez nommer la page comme vous le souhaitez.
Lorsque les témoins tiers ne sont pas disponibles, Auth0.js affiche un iframe pour appeler un autre flux de vérification en authentification inter-origine. 2. Accédez à Auth0 Dashboard > Applications > Applications, puis sélectionnez l’application à consulter. 3. Sous authentification inter-origine, ajoutez l’URL de la page de rappel que vous avez créée dans le champ Cross-Origin Verification Fallback URL.
Pour les environnements de production, vérifiez que l’URL de la page ne pointe pas vers localhost. La page doit se trouver dans le même domaine que celui où le formulaire de connexion intégrée est hébergé et doit utiliser le protocole https.
  1. Cliquez sur Save Changes.
Pour en savoir plus, consultez l’exemple d’authentification inter-origine sur GitHub.

​
Codes d’erreur et descriptions

Les descriptions d’erreur sont rédigées en langage clair. Elles peuvent changer en tout temps et ne doivent pas être analysées par du code.
Lorsque Auth0.js v9 (et Lock) est utilisé pour la connexion intégrée, il appelle le point de terminaison /co/authenticate, qui renvoie les erreurs suivantes :
StatutCodeDescription
400invalid_requestCorps de requête invalide. Tous les paramètres suivants, et eux seuls, sont requis : client_id, credential_type, username, otp et realm.
400unsupported_credential_typeParamètre de type d’identifiant inconnu.
400invalid_requestrealm inconnu : non-existent-connection.
401unauthorized_clientConnexion inter-origine non autorisée.
401password_leakedCette tentative de connexion a été bloquée, car le mot de passe que vous utilisez a déjà été divulgué dans le cadre d’une atteinte aux données (pas dans cette application).
403access_deniedCourriel ou mot de passe incorrect.
403access_deniedErreur d’authentification
403blocked_userUtilisateur bloqué
429too_many_attemptsVotre compte a été bloqué après plusieurs tentatives de connexion consécutives. Nous vous avons envoyé une notification à votre mode de contact privilégié avec des instructions pour le débloquer.
429too_many_attemptsNous avons détecté un comportement de connexion suspect, et toute nouvelle tentative sera bloquée. Veuillez communiquer avec l’administrateur.
De plus, vous pouvez aussi recevoir une erreur 403 générique sans propriété error ni error_description. Le corps de la réponse inclurait simplement quelque chose de semblable à ce qui suit : Origin https://test.app is not allowed.

​
Prise en charge des tests sur navigateur

Les navigateurs suivants peuvent utiliser l’authentification inter-origine lorsque les témoins tiers sont désactivés :
  • Microsoft Internet Explorer

Attributs de témoin SameSite

Auparavant, les valeurs possibles de l’attribut de témoin samesite étaient true, false, strict ou lax. Si vous ne définissiez pas l’attribut manuellement, Auth0 utilisait la valeur par défaut false.À partir de février 2020, Google Chrome v80 a modifié la façon dont il gère les témoins, et Auth0 a mis en œuvre les changements suivants en conséquence :
  • Les témoins sans attribut samesite défini seront définis 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émoins du navigateur.
Ces changements visent à améliorer la sécurité et à contribuer à atténuer les attaques de falsification de requêtes intersites (CSRF).

​
Pour en savoir plus