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

Pour configurer les fonctionnalités d’Auth0 afin d’utiliser votre , vous pourriez devoir suivre des étapes supplémentaires selon les fonctionnalités que vous utilisez. Par exemple, vous pourriez devoir apporter des modifications avant de pouvoir utiliser votre domaine personnalisé sur votre page de connexion ou pour effectuer des requêtes à 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 indiqué ci-dessous, y compris pour tout VPN ou pare-feu que vous utilisez. Notez que les sessions existantes créées à {yourDomain} ne seront plus valides une fois que vous commencerez à utiliser votre domaine personnalisé; les utilisateurs devront donc se connecter de nouveau.

Prérequis

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

Fonctionnalités

Fonctionnalité	Section à lire
Universal Login avec une page de connexion personnalisée	Universal Login
Lock intégré dans votre application	Embedded Lock
Auth0 SPA SDK, Auth0.js ou d’autres SDK Auth0	Auth0 SPA SDK, Auth0.js et autres SDK
Domaine personnalisé avec les courriels Auth0 et les notifications téléphoniques	Utiliser des domaines personnalisés dans les courriels et les notifications téléphoniques
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 Web Service Federation (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

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 la documentation sur d’Auth0. 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 omitted par souci de concision
  configurationBaseUrl: config.clientConfigurationBaseUrl,
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omitted par souci de concision
});

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

var webAuth = new auth0.WebAuth({
  clientID: config.clientID,
  domain: config.auth0Domain,
  //code omitted for brevity (début)
  overrides: {
  	__tenant: config.auth0Tenant,
  	__token_issuer: config.authorizationServer.issuer
  },
  //code omitted for brevity
});

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

Embedded Lock

Si vous utilisez Lock for Web intégré à votre application, vous devez mettre à jour le code pour utiliser votre domaine personnalisé lors de l’initialisation de Lock. Vous devrez également définir configurationBaseUrl sur l’URL du 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 tenants créés avant le 11 juin 2020 doivent utiliser https://cdn.auth0.com si la région correspond aux États-Unis, ou ajouter eu, au ou jp pour l’Europe, l’Australie ou le Japon. Si votre tenant a été créé après le 11 juin 2020, utilisez https://cdn.us.auth0.com si la région correspond aux États-Unis.

Auth0 SPA SDK, Auth0.js et autres SDK

Si vous utilisez 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 ce qui suit : Et pour Auth0 SPA SDK : Consultez la section des API ci-dessous si vous utilisez un domaine personnalisé et souhaitez aussi effectuer des actions de la Management API avec Auth0.js.

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

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

Accédez à Auth0 Dashboard > Branding > Custom Domains.
Activez la bascule Use Custom Domain in Emails.

Si vous voulez utiliser votre domaine personnalisé avec des sociaux (IdP), 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 de 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 . Dans la Google Cloud Console, accédez à Identifiants, choisissez votre client OAuth dans la liste, puis vous verrez une page de paramètres avec le de l’application, le secret et d’autres champs. Dans le champ URI de redirection autorisées, 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 changeront pas. Il s’agit d’une valeur constante pour chaque API et, bien qu’il soit d’usage d’utiliser un URI, elle est complètement indépendante du domaine utilisé pour obtenir le jeton. Auth0 émet des jetons avec la revendication iss du domaine que vous avez utilisé pour obtenir le jeton. Continuez à utiliser le nom de domaine par défaut de votre tenant (comme https://{yourDomain}/userinfo et https://{yourDomain}/api/v2/) plutôt que votre domaine personnalisé lorsque vous précisez une audience. C’est le seul cas où vous devez utiliser le domaine par défaut de votre tenant. Toutes les requêtes (c.-à-d. pour obtenir le jeton et pour appeler l’API) doivent utiliser le même domaine. Les jetons obtenus au moyen d’un domaine personnalisé doivent être utilisés avec une API Auth0 qui utilise ce même domaine personnalisé. Si vous utilisez un flux d’authentification avec votre domaine personnalisé pour demander des afin d’accéder à la , vous devez également 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/

Votre requête de jeton d’accès devrait ressembler à ceci

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

Headers:
Authorization: Bearer <access_token>

Si vous utilisez Auth0 avec un domaine personnalisé pour émettre des jetons d’accès pour vos API, vous devez valider le ou les émetteurs du en les comparant à 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 omitted par souci de brièveté
}));

Configurer les fournisseurs d’identité SAML

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

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 comprendront l’URL ACS mise à jour. Vous devrez ensuite mettre à jour manuellement cette valeur dans les paramètres de votre ou vos IdP. Cette modification à votre ou vos IdP doit être effectuée en même temps que vous commencez à utiliser votre domaine personnalisé dans vos applications. Cela peut poser problème s’il y a plusieurs IdP à configurer.
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 depuis https://<TENANT>.auth0.com/pem. Notez que https://<YOUR-CUSTOM-DOMAIN>.com/pem renverra le même certificat
Remettez le certificat au ou aux IdP afin qu’ils le téléversent. 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 la signature devra être activée (les étapes exactes varient selon l’IdP)
Activez la 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. Puisque la requête signée de votre application est approuvée, 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. Si c’est le cas, vous éviterez d’avoir à modifier en même temps un ou plusieurs paramètres d’IdP et pourrez les préparer à accepter vos requêtes signées à l’avance. Vous pourrez ensuite aussi 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 au moyen 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 le ou les IdP ainsi que votre ou vos applications en même temps afin d’utiliser le domaine personnalisé.

Configurer les 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 qui reflètent le domaine personnalisé à l’adresse https://<YOUR-CUSTOM-DOMAIN>/samlp/metadata/<YOUR-CLIENT-ID>. Notez que l’ID d’entité de l’émetteur de l’assertion renvoyée par Auth0 changera lorsque vous utiliserez un domaine personnalisé (par exemple, il passera 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 devriez utiliser https://<YOUR-CUSTOM-DOMAIN>/samlp/<YOUR-CLIENT-ID>.

Configurer les applications WS-Fed

Si vous voulez utiliser votre domaine personnalisé avec des applications en utilisant Auth0 comme 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 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 des connexions Azure AD, vous devez mettre à jour l’URL de réponse autorisée dans vos paramètres Azure AD. Dans Azure Active Directory, accédez à Inscriptions d’applications et sélectionnez votre application. Cliquez ensuite sur Paramètres -> URL de réponse 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 modifier afin d’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 additionnelle. Pour utiliser des connexions AD/LDAP avec la prise en charge de Kerberos, vous devrez mettre à jour le point de terminaison Ticket pour qu’il fonctionne avec le domaine personnalisé. Comme il est indiqué dans la documentation du connecteur AD/LDAP d’Auth0, le fichier config.json doit être modifié 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 AD/LDAP Connector pour que le changement prenne effet.

Personnalisation de la marque

Personnalisation du code

Personnalisation tierce

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

Prérequis

Fonctionnalités

Embedded Lock

Auth0 SPA SDK, Auth0.js et autres SDK

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

Configurer les connexions Google Workspace

APIs

Configurer les fournisseurs d’identité SAML

Configurer les applications SAML

Configurer les applications WS-Fed

Configurer les connexions Azure AD

Configurer les connexions ADFS

Configurer les connexions AD/LDAP

En savoir plus

​Prérequis

​Fonctionnalités

​Universal Login

​Embedded Lock

​Auth0 SPA SDK, Auth0.js et autres SDK

​Utiliser des domaines personnalisés dans les courriels et les notifications téléphoniques

​Configurer les fournisseurs d’identité sociaux

​Configurer les connexions Google Workspace

​APIs

​Configurer les fournisseurs d’identité SAML

​Configurer les applications SAML

​Configurer les applications WS-Fed

​Configurer les connexions Azure AD

​Configurer les connexions ADFS

​Configurer les connexions AD/LDAP

​En savoir plus

Prérequis

Fonctionnalités

Universal Login

Embedded Lock

Auth0 SPA SDK, Auth0.js et autres SDK

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

Configurer les fournisseurs d’identité sociaux

Configurer les connexions Google Workspace

APIs

Configurer les fournisseurs d’identité SAML

Configurer les applications SAML

Configurer les applications WS-Fed

Configurer les connexions Azure AD

Configurer les connexions ADFS

Configurer les connexions AD/LDAP

En savoir plus