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 , 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.
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.
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.
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é.
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.
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).
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.
API Auth0
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/clientsHeaders: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 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é}));
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é.
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>.
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.
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).
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).
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.
Authentifier
Gérer les utilisateurs
Personnaliser
Plateforme