Meilleures pratiques en matière d’anatomie de connexion à la base de données personnalisées

Vous utilisez généralement une connexion à la base de données personnalisée pour accéder à votre propre magasin d’identités hérité pour l’authentification (parfois appelé authentification héritée) ou pour effectuer l’importation d’utilisateurs par le biais de la migration automatique (souvent appelée migration progressive ou paresseuse). Vous pouvez également utiliser des connexions à la base de données personnalisée pour faire office de proxy d’accès à un locataire Auth0 dans des scénarios où vous utilisez l’architecture multi-locataire d’Auth0. Pour en savoir plus, veuillez lire Meilleures pratiques en matière d’applications multi-locataires.

Vous créez et configurez généralement des connexions de base de données personnalisées en utilisant le Auth0 Dashboard. Vous créez une connexion de base de données, puis activez Utiliser ma propre base de données pour permettre l’édition des scripts d’action de base de données. Une connexion de base de données personnalisée peut également être créée et configurée avec l’Auth0 Management API Créer un point de terminaison de connexion et la stratégie auth0 .

Comme indiqué ci-dessous, vous utilisez des connexions à la base de données personnalisées dans un flux de connexion afin d’obtenir des informations sur l’identité de l’utilisateur à partir de votre propre magasin d’identités hérité pour l’authentification ou l’importation d’utilisateurs.

Outre les artefacts communs à tous les types de connexion à la base de données, une connexion à la base de données personnalisée vous permet de configurer des scripts d’action, c’est-à-dire du code personnalisé utilisé lors de l’interface avec les magasins d’identités hérités. Les scripts que vous choisissez de configurer dépendent de si vous créez une connexion pour l’authentification héritée ou pour la migration automatique.

Les scripts d’action peuvent être mis en œuvre sous la forme de fonctions anonymes. Cependant, les fonctions anonymes compliquent le débogage lorsqu’il s’agit d’interpréter la pile d’appels générée à la suite de conditions d’erreur exceptionnelle. Pour des raisons pratiques, nous recommandons d’établir un nom de fonction pour chaque script d’action. Pour connaître certains noms recommandés, lisez Custom Database Action Script Execution Best Practices (les meilleures pratiques en matière d’exécution de scripts d’action de bases de données personnalisées).

Dans un scénario d’authentification hérité, aucun nouvel enregistrement d’utilisateur n’est créé; l’utilisateur reste dans le magasin d’identités hérité et Auth0 utilise l’identité qu’il détient lors de l’authentification de l’utilisateur. Les connexions à la base de données personnalisées sont également utilisées en dehors du flux de travail de la connexion universelle. Par exemple, le script d’actions changePassword d’une connexion est appelé lorsqu’une opération de changement de mot de passe se produit pour un utilisateur résidant dans un magasin d’identités hérité.

Pendant la migration automatique, Auth0 crée un nouvel utilisateur dans un magasin d’identité (base de données) géré par Auth0. Auth0 utilise l’identité contenue dans le magasin d’identité géré par Auth0 lors de l’authentification de l’utilisateur. Pour ce faire, Auth0 exige premièrement que l’utilisateur soit authentifié auprès du magasin d’identité hérité, et ce n’est qu’en cas de succès que le nouvel utilisateur sera créé dans la base de données gérée par Auth0. Auth0 crée le nouvel utilisateur en utilisant le même ID et le même mot de passe que ceux fournis lors de l’authentification.

La création d’utilisateurs dans un scénario de migration automatique se produit généralement une fois que le script d’action de Connexion s’achève. Nous vous recommandons de ne pas essayer de supprimer les utilisateurs issus d’un magasin d’identités hérité en tant qu’opération incorporée dans le script Connexion, mais plutôt comme un processus indépendant. Cela permet d’éviter la suppression accidentelle d’un utilisateur en cas d’erreur lors de la migration.

Avec la migration automatique, les utilisateurs restent dans le magasin d’identités hérité et peuvent être supprimés ou archivés si nécessaire. Un effet secondaire peut se produire lorsqu’un utilisateur est supprimé d’Auth0 mais reste dans le magasin de données hérité. Dans ce cas, une connexion effectuée par l’utilisateur supprimé pourrait entraîner l’exécution du script Login (Connexion) ou Get User (Obtenir un utilisateur) et une nouvelle migration de l’utilisateur à partir du magasin d’identités hérité.

Nous vous recommandons de marquer les identités des utilisateurs de magasins hérités comme migrées avant la fin des scripts Login ou Get User et avant toute suppression éventuelle de magasins hérités afin d’éviter la recréation involontaire d’utilisateurs supprimés intentionnellement.

Nous recommandons l’utilisation d’un script d’action dont le poids total ne dépasse pas 100 Ko. Plus il est lourd, plus la latence est importante en raison du processus d’emballage et de transport utilisé par la plateforme Auth0, ce qui aura un impact sur les performances de votre système. Notez que la limite de 100 ko n’inclut pas les modules npm qui peuvent être référencés dans le cadre d’une déclaration d’ exigence .

• Meilleures pratiques en matière de sécurité pour les connexions à des bases de données personnalisées
• Meilleures pratiques pour les bases de données personnalisées et l’exécution des scripts d’action
• Meilleures pratiques en matière d’environnement des scripts d’action des bases de données personnalisées