Skip to main content
Lorsque vous utilisez plusieurs domaines personnalisés, vous devez configurer vos SDK Auth0 pour qu’ils utilisent le domaine personnalisé approprié pour l’authentification. Ce guide explique la configuration des SDK sur différentes plateformes et dans différents scénarios.

Concepts clés

Paramètre de domaine

Tous les SDK Auth0 exigent un paramètre domain qui indique quel domaine Auth0 utiliser pour l’authentification. Si vous utilisez des domaines personnalisés, définissez ce paramètre sur votre domaine personnalisé plutôt que sur votre domaine canonique Auth0. Sans domaine personnalisé :
Avec un domaine personnalisé :

Émetteur du jeton

Lorsque vous utilisez un domaine personnalisé, la revendication iss (émetteur) des jetons est définie sur votre domaine personnalisé :
Vous devez configurer la validation du jeton afin d’accepter votre domaine personnalisé comme émetteur valide.

SDK d’authentification

Lorsque vous utilisez MCD, le client est responsable de fournir et de valider tous les domaines personnalisés. Lorsque vous configurez les SDK pour résoudre les domaines personnalisés du locataire à l’aide des fonctions de résolution de domaine, vous devez vous assurer que tous les domaines résolus sont dignes de confiance. Une mauvaise configuration du résolveur de domaine peut permettre de contourner l’authentification auprès de la partie de confiance ou exposer l’application à une falsification de requêtes côté serveur. Si vos domaines et vos serveurs proxy ne sont pas configurés correctement, cela peut créer des vulnérabilités de sécurité critiques dont Okta ne peut être tenue responsable.

SDK Auth0 SPA (JavaScript)

Pour les applications à page unique qui utilisent le SDK Auth0 SPA :

Next.js

Pour les applications Next.js qui utilisent le SDK Next.js d’Auth0 (v4+) : Concepts clés de MCD avec Next.js :
  • Un seul locataire Auth0, plusieurs domaines : Tous les domaines personnalisés partagent le même clientId et le même clientSecret, puisqu’ils appartiennent au même locataire Auth0.
  • Fonction DomainResolver : Le paramètre domain accepte une fonction (config: { headers: Headers; url?: URL }) => Promise<string> | string. Cela permet de résoudre le domaine dynamiquement pour chaque requête selon les en-têtes de la requête entrante.
  • Mise en cache des instances : Le SDK met automatiquement en cache les instances Auth0Client par domaine au moyen d’un cache LRU borné (maximum de 100 entrées) afin d’améliorer les performances.
  • Isolation des sessions : Les sessions créées au moyen d’un domaine personnalisé sont isolées à ce domaine et ne peuvent pas être utilisées de façon interchangeable avec des sessions d’un autre domaine.
  • Paramètre URL : Le paramètre url dans le résolveur vaut undefined dans les Server Components et les Server Actions; il est seulement disponible dans le middleware ou les routes d’API.
  • Ajustement du cache de découverte : Configurez la mise en cache des métadonnées OIDC avec l’option discoveryCache :

SDK React d’Auth0

Pour les applications React utilisant le SDK React d’Auth0 :
Dans les scénarios à plusieurs domaines :

Auth0.js

Pour les applications utilisant Auth0.js :

Node.js (Express)

Pour les applications Node.js qui utilisent express-openid-connect :
Dans les scénarios multilocataires :

SDK pour appareils mobiles

iOS (Swift)

Avec Auth0.swift :
Pour sélectionner le domaine dynamiquement :

Android (Kotlin)

Avec Auth0.Android :
Pour prendre en charge plusieurs domaines :

React Native

Avec react-native-auth0 :

Flutter

Avec flutter_auth0 :

SDK de gestion

Les SDK de gestion permettent d’interagir avec la Management API d’Auth0. Si vous utilisez des domaines personnalisés, vous devrez peut-être inclure l’en-tête auth0-custom-domain ou utiliser le domaine par défaut.

SDK de gestion pour Node.js

SDK de gestion pour Python

SDK de gestion pour Go

Validation du jeton

Lorsque vous utilisez des domaines personnalisés, mettez à jour la validation de votre jeton pour qu’elle accepte le domaine personnalisé comme émetteur.

Node.js (Express)

Avec express-jwt ou jose :
Pour plusieurs domaines personnalisés :

Python (Flask)

À l’aide de python-jose :

Java (Spring Boot)

Avec Spring Security :

Configuration propre à chaque environnement

Utilisez des variables d’environnement pour gérer les domaines personnalisés selon l’environnement :

Structure du fichier .env

Chargement de la configuration

Dépannage

Problèmes courants

ProblèmeCauseSolution
Erreur d’émetteur invalideLa validation du jeton s’attend au domaine canonique, mais reçoit un domaine personnaliséMettez à jour la validation du jeton pour accepter le domaine personnalisé comme émetteur
Échec de la récupération du JWKSL’URI du JWKS pointe vers le domaine canoniqueMettez à jour l’URI du JWKS pour utiliser le domaine personnalisé : https://custom-domain/.well-known/jwks.json
URI de redirection non concordanteL’URL de rappel ne correspond pas aux URI de redirection configuréesAjoutez l’URL de rappel du domaine personnalisé aux paramètres de l’application
Erreurs d’origine croisée (CORS)Le domaine personnalisé ne figure pas parmi les origines autoriséesAjoutez le domaine personnalisé à Allowed Web Origins dans les paramètres de l’application
Échec du chargement de LockLe paramètre configurationBaseUrl est absentAjoutez le paramètre configurationBaseUrl avec l’URL du CDN régional

Bonnes pratiques

  1. Utilisez des variables d’environnement : stockez les domaines personnalisés dans des fichiers de configuration propres à chaque environnement
  2. Validez plusieurs émetteurs : si vous utilisez plusieurs domaines personnalisés, configurez la validation des jetons pour les accepter tous comme émetteurs valides
  3. Mettez à jour les URL de rappel : assurez-vous que tous les domaines personnalisés sont ajoutés à Allowed Callback URLs dans les paramètres de l’application
  4. Testez de façon approfondie : testez l’authentification avec chaque domaine personnalisé avant la mise en production
  5. Surveillez les émetteurs de jetons : consignez et surveillez la revendication iss dans les jetons pour vous assurer que le bon domaine personnalisé est utilisé
  6. Documentez les mappages de domaines : tenez à jour une documentation claire indiquant quelles applications utilisent quels domaines personnalisés
  7. Gérez correctement les échecs : implémentez une gestion des erreurs appropriée pour les échecs d’authentification
  8. Mettez en cache JWKS : mettez en cache les données JWKS pour améliorer les performances et réduire le nombre de requêtes

En savoir plus