Skip to main content
Vous pouvez utiliser différents espaces réservés comme texte dynamique dans vos URL.

​
Fonctionnement de l’évaluation des URL

Une URL contenant l’espace réservé {organization_name} ne sera évaluée que si toutes les conditions suivantes sont remplies :
  • L’application a organization_usage défini sur allow ou require
  • Une transaction a été effectuée dans le contexte d’une organisation (par exemple, en lançant une transaction d’autorisation avec le paramètre organization : /authorize?organization=org_bVss9Do3994SIbiH&…)
Les URL contenant l’espace réservé {organization_name} seront évaluées en plus des URL à correspondance exacte (https://app.exampleco.com) et des URL avec caractères génériques (https://*.exampleco.com). Vous ne devez pas vous fier à un ordre d’évaluation précis des URL. Évitez d’enregistrer, dans le même champ de configuration d’une application, des URL contenant à la fois des caractères génériques et des espaces réservés d’organisation, car cela peut entraîner un comportement indésirable et compliquer le dépannage. Par exemple, prenons une application ayant deux URL de rappel autorisées : https://*.exampleco.com et https://{organization_name}.exampleco.com. Une redirect_uri ayant la valeur https://company-a.exampleco.com serait considérée comme valide même si aucune organisation nommée company-a n’était enregistrée dans votre tenant; cela est dû à l’évaluation du caractère générique.

​
Espaces réservés génériques dans les URL

Les espaces réservés génériques dans les sous-domaines ne doivent pas être utilisés dans les applications de production. Auth0 recommande d’utiliser, lorsqu’il y a lieu, des URL avec l’espace réservé {organization_name}.
Les espaces réservés génériques dans les URL ne sont pas pris en charge pour les applications tierces dotées de contrôles de sécurité renforcés. Les URL de rappel, les origines autorisées et les origines Web doivent utiliser des URL exactes.
Gérez ces paramètres dans Dashboard > Applications > Applications, dans les champs suivants :
  • URL de rappel autorisé : Liste des URL vers lesquelles Auth0 peut rediriger les utilisateurs après leur authentification.
  • URL de déconnexion autorisé : Liste des URL vers lesquelles vous pouvez rediriger les utilisateurs après leur déconnexion d’Auth0.
  • Allows Web Origins : Liste des URL d’où peut provenir une requête d’autorisation utilisant Cross-Origin Authentication, Device Flow et web_message as the response mode.
  • origine autorisé (CORS) : Liste des URL autorisées à effectuer des requêtes JavaScript vers l’API Auth0 (généralement avec CORS).
Évitez d’utiliser des espaces réservés génériques pour les sous-domaines dans les callbacks et les origines autorisées des applications de production, car cela peut rendre votre application vulnérable aux attaques. Vous pouvez utiliser le symbole étoile (*) comme caractère générique pour les sous-domaines, mais il doit respecter les règles suivantes pour fonctionner correctement :
  • Le protocole de l’URL doit être http ou https. Les protocoles comme com.example.app et service:jmx:rmi ne fonctionneront pas.
  • Le caractère générique doit se trouver dans un sous-domaine, à l’intérieur du composant hostname. https://*.com ne fonctionnera pas.
  • Le caractère générique doit se trouver dans le sous-domaine le plus éloigné du domaine racine. https://sub.*.example.com ne fonctionnera pas.
  • L’URL ne doit pas contenir plus d’un caractère générique. https://*.*.example.com ne fonctionnera pas.
  • Un caractère générique peut être précédé ou suivi d’autres caractères valides du hostname. https://prefix-*-suffix.example.com fonctionnera.
  • Une URL comportant un caractère générique valide ne correspondra pas à une URL comportant plus d’un niveau de sous-domaine à la place du caractère générique. https://*.example.com ne fonctionnera pas avec https://sub1.sub2.example.com.

​
Espaces réservés d’URL pour organisation

​
Espace réservé pour le nom de l’organisation

Vous pouvez utiliser {organization_name} comme espace réservé pour indiquer dynamiquement le nom d’une organisation enregistrée dans une URL (https://{organization_name}.exampleco.com). Les URL qui contiennent l’espace réservé {organization_name} ne doivent être utilisées que sur des domaines que vous contrôlez entièrement. Par exemple, si vous contrôlez le domaine exampleco.com, l’espace réservé avec le nom de votre organisation est https://{organization_name}.exampleco.com. Gérez ces paramètres dans Dashboard > Applications > Applications dans les champs suivants :
  • URL de rappel autorisé : liste des URL vers lesquelles Auth0 peut rediriger les utilisateurs après leur authentification.
  • origine autorisé (CORS) : liste des URL autorisées à envoyer des requêtes en Javascript à Auth0 API (généralement avec CORS).
Les restrictions suivantes s’appliquent lorsque vous utilisez l’espace réservé {organization_name} :
  • Le protocole de l’URL doit être http: ou https:. com.example.app://{organization_name}.exampleco.com ne fonctionnera pas.
  • L’espace réservé doit se trouver dans un sous-domaine, à l’intérieur du composant de nom d’hôte. https://{organization_name} et https://exampleco.com/{organization_name} ne fonctionneront pas.
  • L’espace réservé doit se trouver dans le sous-domaine le plus éloigné du domaine racine. https://sub.{organization_name}.exampleco.com ne fonctionnera pas.
  • L’URL ne doit pas contenir plus d’un espace réservé. https://{organization_name}.{organization_name}.exampleco.com ne fonctionnera pas.
  • Un espace réservé ne doit pas être précédé ou suivi d’autres caractères valides de nom d’hôte. https://prefix-{organization_name}-suffix.exampleco.com ne fonctionnera pas.
  • Un espace réservé ne doit pas être utilisé avec un caractère générique dans l’URL. https://{organization_name}.*.exampleco.com ne fonctionnera pas.

​
Espace réservé des métadonnées de l’organisation

Vous pouvez utiliser {organization.metadata.KEY} comme espace réservé pour définir dynamiquement une URL en fonction des métadonnées associées à l’Organisation dans la requête en cours. Cela est utile lorsque différentes Organisations nécessitent des URI de connexion différentes, par exemple lorsque chaque Organisation correspond à un domaine personnalisé distinct. La KEY doit commencer par public_ ou PUBLIC_ (par exemple, {organization.metadata.public_login_host}). Les clés sans ce préfixe sont ignorées à l’exécution pour des raisons de sécurité. Auth0 prend en charge cet espace réservé pour l’URI de connexion de l’application (initiate_login_uri). Pour en savoir plus, consultez URI de connexion dynamiques avec des espaces réservés de métadonnées. Les mêmes règles de validation qui s’appliquent aux espaces réservés de domaine personnalisé s’appliquent aussi aux espaces réservés des métadonnées de l’Organisation (protocole, emplacement, imbrication, aucun caractère générique, type de données).
Les espaces réservés des métadonnées de l’organisation exigent que la requête s’inscrive dans le contexte d’une Organisation. Si aucune organisation n’est présente, l’espace réservé ne peut pas être résolu et Auth0 utilise alors la valeur default_redirection_uri au niveau du tenant.

​
Espaces réservés d’URL pour les domaines personnalisés

Vous pouvez utiliser {custom_domain.metadata.KEY} comme espace réservé pour indiquer dynamiquement une URL en fonction des métadonnées associées au domaine personnalisé utilisé dans la requête. Cela vous permet de prendre en charge plusieurs domaines personnalisés avec des URL d’application différentes dans un même tenant. Pour un aperçu complet de cette fonctionnalité, consultez Domaines personnalisés multiples

​
Règles de validation

Les valeurs de métadonnées utilisées comme espaces réservés dans les URL peuvent être exposées aux utilisateurs finaux pendant les flux d’authentification. N’utilisez pas de métadonnées sensibles dans les espaces réservés. Toutes les clés de métadonnées utilisées dans les espaces réservés doivent commencer par public_ afin que cela soit explicite.
Les restrictions suivantes s’appliquent lors de l’utilisation des espaces réservés du domaine personnalisé :
  • Préfixe Public requis : La clé de métadonnées utilisée dans l’espace réservé doit commencer par public_ ou PUBLIC_ (par exemple, {custom_domain.metadata.public_callback_subdomain}). Les clés sans ce préfixe sont ignorées à l’exécution pour des raisons de sécurité.
    • Protocole : Le protocole de l’URL doit être http ou https.
    • Emplacement : L’espace réservé doit se trouver dans la partie domaine ou sous-domaine. Il ne peut pas être utilisé dans le chemin de l’URL.
      • Valide : https://{custom_domain.metadata.public_app_url}.example.com/login
      • Invalide : https://example.com/{custom_domain.metadata.public_path}
    • Imbrication : Vous ne pouvez pas accéder à des propriétés de métadonnées imbriquées. Seules les clés de premier niveau sont prises en charge.
    • Aucun caractère générique : Un espace réservé de domaine personnalisé ne doit pas être utilisé conjointement avec un caractère générique (*) dans la même URL.
    • Type de données : La valeur dans les métadonnées du domaine personnalisé doit être une String. Si la clé n’existe pas ou si la valeur n’est pas une String, l’URL est ignorée lors de la validation.

​
Champs pris en charge

Ces espaces réservés peuvent être configurés pour les URL d’application suivantes : Pour en savoir plus, consultez Paramètres de l’application.
Les espaces réservés du domaine personnalisé ne sont pas pris en charge pour les applications tierces.

​
Utilisation avec les espaces réservés d’organisation

Vous pouvez combiner l’espace réservé de domaine personnalisé avec l’espace réservé {organization_name}, tant que votre flux le prend en charge. Les deux espaces réservés sont évalués et remplacés à l’exécution.

​
En savoir plus