Passer au contenu principal
Vous pouvez utiliser divers espaces réservés comme texte dynamique dans vos URL.

​
Comment fonctionne l’évaluation des URL

Une URL contenant un 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 avec 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 présumer d’un ordre d’évaluation particulier 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 avec deux Allowed Callback URLs : https://*.exampleco.com et https://{organization_name}.exampleco.com. Un redirect_uri ayant la valeur https://company-a.exampleco.com serait considéré comme valide même si aucune organisation nommée company-a n’était enregistrée dans votre locataire; cela est dû à l’évaluation du caractère générique.

​
Espaces réservés de caractère générique dans les URL

Les espaces réservés de caractère générique dans les sous-domaines ne devraient pas être utilisés dans les applications de production. Auth0 recommande d’utiliser des URL avec l’espace réservé {organization_name} lorsqu’approprié.
Les espaces réservés de caractère générique dans les URL ne sont pas pris en charge pour les applications tierces avec des 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 Auth0 Dashboard > Applications > Applications dans les champs suivants :
  • Allowed Callback URLs : Liste des URL vers lesquelles Auth0 est autorisé à rediriger les utilisateurs après leur authentification.
  • Allowed Logout URLs : 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 demande d’autorisation utilisant l’authentification inter-origine, le flux d’appareil et web_message comme mode de réponse.
  • Allowed Origins (CORS) : Liste des URL autorisées à effectuer des requêtes en JavaScript vers l’API Auth0 (généralement avec CORS).
Évitez d’utiliser des espaces réservés de caractère générique pour les sous-domaines dans les URL de rappel 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 du composant de nom d’hôte. 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.
  • Le caractère générique peut être précédé ou suivi d’autres caractères valides du nom d’hôte. https://prefix-*-suffix.example.com fonctionnera.
  • Une URL avec 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 dans l’URL de l’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 contenant 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 Auth0 Dashboard > Applications > Applications, dans les champs suivants :
  • Allowed Callback URLs : Liste des URL vers lesquelles Auth0 est autorisé à rediriger les utilisateurs après leur authentification.
  • Allowed Origins (CORS) : Liste des URL autorisées à effectuer des requêtes en JavaScript vers l’API Auth0 (généralement utilisée avec CORS).
Les restrictions suivantes s’appliquent à l’utilisation de 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 du nom d’hôte. https://{organization_name} ou 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é de métadonnées d’Organisation

Vous pouvez utiliser {organization.metadata.KEY} comme espace réservé pour spécifier 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 différentes URI de connexion, par exemple lorsque chaque Organisation correspond à un domaine personnalisé distinct. Le KEY doit commencer par public_ ou PUBLIC_ (par exemple, {organization.metadata.public_login_host}). Les clés sans ce préfixe sont ignorées dans l’environnement d’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 également aux espaces réservés de métadonnées d’Organisation (protocole, emplacement, imbrication, aucun caractère générique, type de données).
Les espaces réservés de métadonnées d’Organisation nécessitent que la requête soit 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 la valeur default_redirection_uri du locataire.

​
Espaces réservés d’URL pour domaine personnalisé

Vous pouvez utiliser {custom_domain.metadata.KEY} comme espace réservé pour définir 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 différentes URL d’application au sein du même locataire. 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 d’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_ pour l’indiquer clairement.
Les restrictions suivantes s’appliquent lors de l’utilisation des espaces réservés de 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 dans l’environnement d’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 des 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 pendant la validation.

​
Champs pris en charge

Ces espaces réservés peuvent être configurés pour les URL d’application suivantes : Pour plus d’informations, consultez Paramètres de l’application.
Les espaces réservés de 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é Domaine personnalisé avec l’espace réservé {organization_name}, à condition que votre flux le prenne en charge. Les deux espaces réservés sont évalués et remplacés à l’exécution.

​
En savoir plus