Configurer les fonctionnalités pour qu’elles utilisent des domaines personnalisés

Découvrez comment configurer un domaine personnalisé pour les fonctionnalités d’authentification d’Auth0.

Pour configurer les fonctionnalités d’Auth0 afin d’utiliser votre domaine personnalisé, vous devrez peut-être suivre des étapes supplémentaires selon les fonctionnalités que vous utilisez. Par exemple, vous devrez peut-être apporter des modifications avant de pouvoir utiliser votre domaine personnalisé sur votre page de connexion ou pour appeler vos API.

Si vous utilisez Auth0 depuis un certain temps et décidez d’activer un domaine personnalisé, vous devrez migrer vos applications existantes et mettre à jour les paramètres comme décrit ci-dessous, y compris ceux de tout VPN ou pare-feu que vous utilisez. Notez que les sessions existantes créées sur {yourDomain} ne seront plus valides une fois que vous commencerez à utiliser votre domaine personnalisé. Les utilisateurs devront donc se reconnecter.

​

Prérequis

Vous devriez avoir déjà configuré et vérifié votre Domaine personnalisé.

​

Fonctionnalités

Fonctionnalité	Section à consulter
Universal Login avec une page de connexion personnalisée	Universal Login
Lock intégré à votre application	Lock intégré
Auth0 SPA SDK, Auth0.js ou d’autres SDK Auth0	Auth0 SPA SDK, Auth0.js et d’autres SDK
Domaine personnalisé avec les courriels Auth0 et les notifications par téléphone	Utiliser des domaines personnalisés dans les courriels et les notifications par téléphone
Fournisseurs d’identité sociaux	Configurer les fournisseurs d’identité sociaux
Connexions Google Workspace avec votre domaine personnalisé	Configurer les connexions Google Workspace
Émettre des jetons d’accès pour vos API ou accéder aux API Auth0 à partir de votre application	API
Fournisseurs d’identité SAML	Configurer les fournisseurs d’identité SAML
Applications SAML	Configurer les applications SAML
Applications WS-Fed	Configurer les applications WS-Fed
Connexions Azure AD	Configurer les connexions Azure AD
Connexions ADFS	Configurer les connexions ADFS
Connexions AD/LAP avec prise en charge de Kerberos	Configurer les connexions AD/LAP

​

Universal Login

Si vous utilisez Auth0 Universal Login et que vous avez personnalisé la page de connexion, vous devez mettre à jour le code pour utiliser votre domaine personnalisé. Si vous utilisez la page de connexion par défaut sans la personnaliser, vous n’avez rien à modifier. Pour en savoir plus, consultez Auth0 Universal Login.

Si vous utilisez Lock for Web, vous devez définir les options configurationBaseUrl et overrides comme dans l’exemple de script suivant :

var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
  //code omis par souci de concision
  configurationBaseUrl: config.clientConfigurationBaseUrl,
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omis par souci de concision
});

Si vous utilisez Auth0.js sur la page Universal Login, vous devez définir l’option overrides.

var webAuth = new auth0.WebAuth({
  clientID: config.clientID,
  domain: config.auth0Domain,
  //code omis par souci de concision
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omis par souci de concision
});

Dans la plupart des cas, les bibliothèques Auth0.js et Lock récupèrent le nom du locataire (requis pour /usernamepassword/login) et l’émetteur (requis pour la validation de id_token) à partir du domaine. Toutefois, si vous êtes un client de Private Cloud qui utilise un proxy ou un nom de domaine personnalisé dans lequel le nom de domaine diffère du locataire ou de l’émetteur, vous pouvez utiliser __tenant et __token_issuer pour fournir vos propres valeurs.

​

Lock intégré

Si vous utilisez Lock for Web intégré dans votre application, vous devez mettre à jour le code afin d’utiliser votre domaine personnalisé lors de l’initialisation de Lock. Vous devrez aussi définir configurationBaseUrl sur l’URL CDN appropriée.

L’URL du CDN varie selon la région. Utilisez https://cdn.[us|eu|au|jp].auth0.com (us pour les États-Unis, eu pour l’Europe, au pour l’Australie ou jp pour le Japon).

L’URL du CDN varie selon la région. Les locataires créés avant le 11 juin 2020 doivent utiliser https://cdn.auth0.com si la région est celle des États-Unis, ou ajouter eu, au ou jp pour l’Europe, l’Australie ou le Japon. Si votre locataire a été créé après le 11 juin 2020, utilisez https://cdn.us.auth0.com si la région est celle des États-Unis.

​

Auth0 SPA SDK, Auth0.js et autres SDK

Si vous utilisez le Auth0 SPA SDK, Auth0.js ou d’autres SDK, vous devrez initialiser le SDK avec votre domaine personnalisé. Par exemple, si vous utilisez le SDK Auth0.js, vous devez définir les éléments suivants :

Et pour le SDK SPA d’Auth0 :

Consultez la section API ci-dessous si vous utilisez un domaine personnalisé et souhaitez également effectuer des actions de la Management API avec Auth0.js.

​

Utiliser des domaines personnalisés dans les courriels et les notifications par téléphone

Si vous souhaitez utiliser votre domaine personnalisé pour vos courriels Auth0 ou vos notifications par téléphone, vous devez activer cette fonctionnalité.

1. Accédez à Auth0 Dashboard > Branding > Custom Domains.
2. Activez l’option Use Custom Domain in Emails.

​

Configurer les fournisseurs d’identité sociaux

Si vous souhaitez utiliser votre domaine personnalisé avec des fournisseurs d’identité (IdP) sociaux, vous devez mettre à jour la liste des URI de redirection autorisées de votre IdP afin d’y inclure votre domaine personnalisé (par exemple, https://login.northwind.com/login/callback).

Vous ne pouvez pas utiliser les clés développeur Auth0 avec des domaines personnalisés.

​

Configurer les connexions Google Workspace

Si vous souhaitez utiliser votre domaine personnalisé avec des connexions Google Workspace, vous devez mettre à jour l’URI de redirection autorisée dans les paramètres de votre client OAuth. Dans la Google Cloud Console, accédez à Credentials, sélectionnez votre client OAuth dans la liste, puis ouvrez la page de paramètres qui affiche l’ID client de l’application, le secret et d’autres champs. Dans le champ Authorized redirect URIs, ajoutez une URL au format https://<YOUR-CUSTOM-DOMAIN>/login/callback qui inclut votre domaine personnalisé (par exemple, https://login.northwind.com/login/callback).

​

APIs

Les identifiants d’API (c.-à-d. audience) ne changent pas. Il s’agit d’une valeur constante pour chaque API et, même s’il est courant d’utiliser un URI, elle est totalement indépendante du Domaine utilisé pour obtenir le jeton.

Auth0 émet des jetons avec la revendication iss correspondant au domaine que vous avez utilisé pour obtenir le jeton.

API Auth0

Continuez à utiliser le nom de domaine par défaut de votre locataire (comme https://{yourDomain}/userinfo et https://{yourDomain}/api/v2/) plutôt que votre domaine personnalisé lorsque vous spécifiez une audience. C’est le seul endroit où vous devez utiliser le nom de domaine par défaut de votre locataire.

Toutes les requêtes (c.-à-d. l’obtention du jeton et l’appel proprement dit à l’API) doivent utiliser le même domaine. Les jetons obtenus par l’intermédiaire d’un domaine personnalisé doivent être utilisés avec une API Auth0 en utilisant ce même domaine personnalisé.

Si vous utilisez un flux d’authentification avec votre domaine personnalisé pour demander des jetons d’accès afin d’accéder à la Management API, vous devez aussi appeler le point de terminaison de la Management API avec votre domaine personnalisé.

POST https://mycustomdomain.com/oauth/token
... // autres paramètres 
...
audience:https://defaulttenant.eu.auth0.com/api/v2/

La requête pour votre jeton d’accès devrait ressembler à ceci

GET https://mycustomdomain.com/api/v2/clients

Headers:
Authorization: Bearer <access_token>

API personnalisées

Si vous utilisez Auth0 avec un domaine personnalisé pour émettre des jetons d’accès pour vos API, vous devez valider l’émetteur ou les émetteurs du JWT en fonction de votre domaine personnalisé. Par exemple, si vous utilisez le middleware express-jwt, vous devez apporter la modification suivante :

app.use(jwt({
  issuer: 'https://<YOUR-CUSTOM-DOMAIN>/',
  //code omis par souci de concision
}));

​

Configurer les fournisseurs d’identité SAML

Pour utiliser votre domaine personnalisé avec des fournisseurs d’identité SAML (IdP), vous devez mettre à jour vos URL ACS (Assertion Consumer Service) auprès des fournisseurs d’identité. Selon ce que l’IdP prend en charge, vous pouvez procéder de l’une des deux façons suivantes :

1. Vous pouvez obtenir les métadonnées du fournisseur de services depuis Auth0 à l’adresse https://<YOUR-CUSTOM-DOMAIN>/samlp/metadata?connection=<YOUR-CONNECTION-NAME>. Elles incluront l’URL ACS mise à jour. Vous devez ensuite mettre à jour manuellement cette valeur dans les paramètres de vos IdP. Cette modification dans vos IdP doit être effectuée au même moment où vous commencez à utiliser votre domaine personnalisé dans vos applications. Cela peut poser problème s’il y a plusieurs IdP à configurer.
2. Si l’IdP le prend en charge, vous pouvez utiliser des requêtes signées pour répondre à cette exigence :

• Téléchargez le certificat de signature à partir de https://<TENANT>.auth0.com/pem. Notez que https://<YOUR-CUSTOM-DOMAIN>.com/pem renverra le même certificat
• Remettez le certificat aux IdP pour qu’ils puissent le téléverser. Cela permet à l’IdP de valider la signature du message AuthnRequest qu’Auth0 envoie à l’IdP
• L’IdP importera le certificat et, au besoin, la vérification de signature devra être activée (les étapes exactes varient selon l’IdP)
• Activez le bouton bascule Sign Request dans le Dashboard sous Connections > Enterprise > SAML > CONNECTION. Cela amènera Auth0 à signer les messages SAML AuthnRequest qu’il envoie à l’IdP.

Une fois cela fait, lorsque vous commencerez à utiliser votre domaine personnalisé pour lancer une requête d’authentification dans votre application, l’IdP recevra ce domaine personnalisé dans votre requête signée. Comme la requête signée de votre application est jugée fiable, l’IdP devrait automatiquement remplacer la valeur configurée comme URL ACS par celle envoyée dans la requête signée. Cependant, certains IdP n’acceptent pas l’URL ACS dans la requête signée; vous devez donc d’abord vérifier auprès du vôtre si cette fonctionnalité est prise en charge ou non.

Si c’est pris en charge, cela vous évitera d’avoir à modifier en même temps les paramètres d’un ou de plusieurs IdP et vous permettra de les préparer à accepter vos requêtes signées à l’avance. Vous pourrez ensuite modifier plus tard l’URL ACS configurée statiquement dans les paramètres de votre IdP.

Notez que si votre fournisseur d’identité SAML est configuré pour utiliser votre domaine personnalisé, le test de la connexion à l’aide du bouton Try dans le Dashboard ne fonctionnera pas et les liens par défaut pour télécharger les métadonnées depuis Auth0 afficheront toujours le domaine par défaut, et non le domaine personnalisé.

Si vous avez un flux d’authentification initié par l’IdP, vous devrez mettre à jour les IdP et vos applications en même temps pour utiliser le domaine personnalisé.

​

Configurer des applications SAML

Si vous souhaitez utiliser votre domaine personnalisé avec des applications SAML (lorsqu’Auth0 est l’IdP), vous devez mettre à jour votre fournisseur de services avec les nouvelles métadonnées du fournisseur d’identité d’Auth0. Vous pouvez obtenir les métadonnées mises à jour correspondant au domaine personnalisé à l’adresse https://<YOUR-CUSTOM-DOMAIN>/samlp/metadata/<YOUR-CLIENT-ID>. Notez que l’ID d’entité de l’émetteur pour l’assertion renvoyée par Auth0 changera lorsque vous utiliserez un domaine personnalisé (par exemple, de urn:northwind.auth0.com à une valeur utilisant le domaine personnalisé, comme urn:login.northwind.com).

Si vous avez un flux d’authentification initié par l’IdP, vous devrez mettre à jour l’URL utilisée pour lancer ce flux afin qu’elle reflète le domaine personnalisé. Au lieu de https://<TENANT>.auth0.com/samlp/<YOUR-CLIENT-ID>, vous devez utiliser https://<YOUR-CUSTOM-DOMAIN>/samlp/<YOUR-CLIENT-ID>.

​

Configurer les applications WS-Fed

Si vous souhaitez utiliser votre domaine personnalisé avec des applications WS-Fed avec Auth0 comme IdP, vous devez mettre à jour votre fournisseur de services avec les nouvelles métadonnées du fournisseur d’identité provenant d’Auth0. Vous pouvez obtenir les métadonnées correspondant au domaine personnalisé à l’adresse https://<YOUR-CUSTOM-DOMAIN>/wsfed/FederationMetadata/2007-06/FederationMetadata.xml.

​

Configurer les connexions Azure AD

Si vous souhaitez utiliser votre domaine personnalisé avec les connexions Azure AD, vous devez mettre à jour l’URL de réponse autorisée dans les paramètres Azure AD. Dans Azure Active Directory, accédez à Apps registrations et sélectionnez votre application. Cliquez ensuite sur Settings -> Reply URLs et ajoutez une URL avec votre domaine personnalisé au format https://<YOUR-CUSTOM-DOMAIN>/login/callback (par exemple, https://login.northwind.com/login/callback).

​

Configurer les connexions ADFS

Si vous souhaitez utiliser votre domaine personnalisé avec des connexions ADFS, vous devez mettre à jour le point de terminaison dans vos paramètres ADFS. Vous devrez le mettre à jour pour utiliser votre domaine personnalisé dans l’URL de rappel au format https://<YOUR-CUSTOM-DOMAIN>/login/callback (par exemple, https://login.northwind.com/login/callback).

​

Configurer les connexions AD/LDAP

Si vous n’avez pas besoin de la prise en charge de Kerberos, les connexions AD/LDAP ne nécessitent aucune configuration supplémentaire.

Pour utiliser les connexions AD/LDAP avec la prise en charge de Kerberos, vous devrez mettre à jour le point de terminaison Ticket pour qu’il fonctionne avec votre domaine personnalisé. Comme indiqué dans la documentation du connecteur AD/LDAP d’Auth0, vous devez modifier le fichier config.json en remplaçant la valeur PROVISIONING_TICKET afin d’utiliser votre domaine personnalisé au format https://<YOUR-CUSTOM-DOMAIN>/p/ad/jUG0dN0R.

Une fois cette modification enregistrée, vous devez redémarrer le service du connecteur AD/LDAP pour qu’elle prenne effet.

​

En savoir plus

• Configurer des domaines personnalisés avec des certificats gérés par Auth0
• Configurer des domaines personnalisés avec des certificats autogérés
• Résoudre les problèmes liés aux domaines personnalisés
• Vérifier les appels d’API
• Résoudre les problèmes de configuration SAML