> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Découvrez comment authentifier des utilisateurs en utilisant votre base de données comme fournisseur d’identité. # Authentifier à l’aide de votre propre répertoire d’utilisateurs Votre forfait Auth0 ou votre entente personnalisée déterminent si cette fonctionnalité est offerte. Pour en savoir plus, consultez [Tarification](https://auth0.com/pricing). Utilisez une connexion de base de données personnalisée lorsque vous voulez donner accès à votre propre référentiel de données d’identité autonome (ancien) aux fins suivantes : * **Authentification** : utilisez votre base de données comme fournisseur d’identité dans Auth0 pour authentifier les utilisateurs. (On parle alors d’authentification existante.) * **Importer des utilisateurs** : utilisez la migration automatique (migration progressive ou à la volée) * **Accès proxy à un locataire Auth0** : utilisez l’architecture multilocataire d’Auth0. Vous pouvez créer et configurer une connexion de base de données personnalisée en effectuant l’une des tâches suivantes : 1. Utilisez le point de terminaison [Create connections](https://auth0.com/docs/api/management/v2#!/Connections/post_connections) avec la stratégie `auth0`. 2. Accédez à [Auth0 Dashboard > Authentication > Database](https://manage.auth0.com/#/connections/database), créez la connexion, puis activez l’option **Use my own database** pour permettre la modification du script d’action de base de données. Activer l’option Use my own database pour une base de données personnalisée
## Fonctionnement
Comme l’illustre le diagramme ci-dessous, vous utilisez des connexions de base de données personnalisées dans le cadre du flux Universal Login afin d’obtenir les renseignements d’identité de l’utilisateur à partir de votre propre référentiel d’identités hérité. Anatomie des connexions de base de données personnalisées En plus des éléments communs à tous les types de [connexions de base de données](/fr-CA/docs/authenticate/database-connections), une connexion de base de données personnalisée vous permet de configurer des scripts d’action : du code personnalisé utilisé pour interagir avec votre référentiel d’identités hérité. Auth0 fournit des [modèles de scripts d’action pour les bases de données personnalisées](/fr-CA/docs/authenticate/database-connections/custom-db/templates) pour la configuration, et ceux que vous utiliserez dépendent du fait que vous créez une connexion de base de données personnalisée pour l’authentification héritée ou pour la migration automatique. Les scripts d’action peuvent être implémentés sous forme de fonctions anonymes. Toutefois, les fonctions anonymes compliquent le débogage lorsqu’il faut interpréter la pile d’appels générée à la suite d’une erreur. Nous vous recommandons donc de donner un nom de fonction à chaque script d’action.
### Scénario d’authentification hérité
Dans un scénario d’authentification hérité, un nouvel enregistrement utilisateur est créé dans Auth0 lors de la première connexion de l’utilisateur, mais Auth0 ne stocke pas le hachage de son mot de passe. Auth0 utilisera toujours le référentiel d’identités hérité et l’identité qu’il contient pour authentifier l’utilisateur. Les connexions de base de données personnalisées sont également utilisées en dehors du flux Universal Login. Par exemple, le script d’action `changePassword` d’une connexion est appelé lorsqu’un utilisateur se trouvant dans un référentiel d’identités hérité effectue une opération de changement de mot de passe.
### Scénario de migration automatique
Lors d’une migration automatique ou progressive, Auth0 crée un nouvel utilisateur dans un magasin d’identités (base de données) géré par Auth0. Par la suite, Auth0 utilise toujours l’identité stockée dans le magasin d’identités géré par Auth0 pour authentifier l’utilisateur. Pour que cela se produise, Auth0 exige d’abord que l’utilisateur soit authentifié auprès de l’ancien magasin d’identités; ce n’est qu’en cas de succès que le nouvel utilisateur sera créé. Le nouvel utilisateur sera créé avec le même id et le même mot de passe que ceux fournis lors de l’authentification. La création d’un utilisateur dans un scénario de migration automatique a généralement lieu une fois le script d’action `login` terminé. Nous vous recommandons donc de ne pas tenter de supprimer un utilisateur de l’ancien magasin d’identités au moyen d’une opération en ligne (c.-à-d. dans le script `login`), mais plutôt d’effectuer cette suppression dans le cadre d’un processus distinct. Vous éviterez ainsi la suppression accidentelle d’un utilisateur si une erreur survient pendant le processus de migration. Dans un scénario de migration automatique, les utilisateurs demeurent dans l’ancien magasin d’identités et peuvent être supprimés ou archivés au besoin. Un effet secondaire peut toutefois se produire si un utilisateur est supprimé d’Auth0, mais est toujours présent dans l’ancien magasin d’identités. Dans ce cas, une tentative de connexion par l’utilisateur supprimé pourrait entraîner l’exécution du script `login` et/ou `getUser`, et l’utilisateur serait alors migré de nouveau depuis l’ancien magasin d’identités. Nous recommandons de marquer toute identité utilisateur existante comme ayant été migrée avant la fin de `login` ou de `getUser`, et avant toute suppression éventuelle de l’ancien magasin d’identités.
## Taille
La taille totale de l’implémentation de tout script Action ne doit pas dépasser 100 kB. Plus cette taille est grande, plus le processus d’empaquetage et de transport utilisé par la plateforme Webtask sans serveur d’Auth0 ajoute de la latence, ce qui a une incidence sur les performances de votre système. La limite de 100 kB n’inclut pas les modules `npm` référencés dans des instructions `require`.
## Environnement
Les scripts Action s’exécutent sous la forme d’une série de fonctions JavaScript appelées dans une instance de conteneur Webtask sans serveur. Dans ce cadre, un environnement précis est fourni, ainsi qu’un certain nombre d’artefacts fournis à la fois par le conteneur Webtask et par le serveur d’authentification Auth0 (votre locataire Auth0) lui-même.
### modules npm
Les conteneurs Webtask serverless d’Auth0 peuvent utiliser une [vaste gamme de modules npm](https://auth0-extensions.github.io/canirequire/) ; les modules `npm` réduisent non seulement la taille globale du code d’implémentation des scripts Action, mais donnent aussi accès à un large éventail de fonctionnalités prédéfinies. De nombreux modules `npm` accessibles au public sont pris en charge d’emblée. La liste a été établie et vérifiée afin de relever tout problème de sécurité potentiel. Si vous avez besoin d’un module `npm` qui n’est pas pris en charge d’emblée, vous pouvez en faire la demande par l’entremise du [portail d’assistance Auth0](https://support.auth0.com) ou de votre représentant Auth0. Auth0 évaluera votre demande afin d’en déterminer la pertinence. À l’heure actuelle, Auth0 ne prend pas en charge l’utilisation de modules `npm` provenant de dépôts privés.
### Variables
Les scripts Action Auth0 prennent en charge les variables d’environnement, accessibles au moyen de ce qu’on appelle l’objet `configuration`, disponible globalement. Pour en savoir plus, consultez la section Add Configuration Parameters dans [Create Custom Database Connections](/fr-CA/docs/authenticate/database-connections/custom-db/create-db-connection). L’objet `configuration` doit être traité comme étant en lecture seule et servir à stocker des renseignements sensibles, comme des identifiants ou des clés d’API permettant d’accéder à des répertoires d’identités externes. Cela évite d’inscrire en dur, dans un script Action, des valeurs sensibles sur le plan de la sécurité. L’objet de configuration peut aussi servir à prendre en charge les stratégies de cycle de vie du développement logiciel (SDLC) que vous utilisez, en vous permettant de définir des variables dont les valeurs sont propres au locataire. Cela atténue le recours à des valeurs codées en dur dans un script Action qui peuvent changer selon le locataire qui l’exécute. Pour plus de détails, voir [Software Development Life Cycle (SDLC)](/fr-CA/docs/get-started/auth0-overview/create-tenants/set-up-multiple-environments).
### objet global
Les conteneurs Webtask sans serveur d’Auth0 sont provisionnés à partir d’un pool associé à chaque locataire Auth0. Chaque instance de conteneur rend l’objet `global` accessible à tous les scripts d’action qui s’exécutent dans cette instance. L’objet `global` agit comme une variable globale propre au conteneur et peut servir à définir des informations ou des fonctions utilisées par tous les scripts d’action qui s’exécutent dans l’instance de conteneur. Cela signifie que l’objet `global` peut être utilisé pour mettre en cache des ressources coûteuses, tant que celles-ci ne sont pas propres à un utilisateur. Par exemple, vous pourriez l’utiliser pour stocker un Jeton d’accès pour une API tierce (de journalisation) qui offre des fonctionnalités non propres à l’utilisateur. Vous pourriez aussi y stocker un jeton d’accès pour votre propre API non propre à l’utilisateur, définie dans Auth0 et obtenu au moyen du [Client Credentials Flow](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow). Un script d’action peut s’exécuter dans n’importe quelle instance de conteneur déjà en cours d’exécution, ou dans une nouvelle instance de conteneur (qui pourrait ensuite être ajoutée au pool). Il n’existe aucune affinité de conteneur pour l’exécution des scripts d’action dans Auth0. Cela signifie que vous devez éviter de stocker dans l’objet `global` toute information propre à un utilisateur et toujours vous assurer que toute déclaration faite dans l’objet `global` prévoit également une initialisation. Chaque fois qu’un conteneur Webtask est recyclé, ou à chaque création d’un nouveau conteneur Webtask, l’objet `global` qu’il définit est réinitialisé. Par conséquent, toute déclaration d’affectation dans l’objet `global` associé à un conteneur doit également prévoir une initialisation. Pour offrir une plus grande flexibilité en matière de performance, les conteneurs Webtask sans serveur sont provisionnés dans Auth0 de façon ponctuelle et sont également soumis à diverses politiques de recyclage. En règle générale, nous vous recommandons de ne pas considérer la durée de vie d’un objet `global` comme dépassant 20 minutes.
## Sécurité
### Accéder au magasin d’identités hérité au moyen d’une API personnalisée
Protéger le magasin d’identités hérité contre tout accès non restreint est une bonne pratique recommandée. Par exemple, exposer directement une base de données à Internet peut être extrêmement problématique : les interfaces de bases de données SQL et similaires offrent des fonctionnalités très étendues, ce qui va à l’encontre du principe du moindre privilège en matière de sécurité. Nous vous recommandons de mettre en place une API afin d’appliquer le principe du moindre privilège à votre magasin d’identités hérité (base de données), plutôt que d’ouvrir simplement un accès général par Internet. L’autre solution consiste à créer une API simple (personnalisée), protégée par un jeton d’accès, que chaque script d’action peut appeler. Elle servirait alors d’interface au magasin d’identités hérité. Le flux Client Credentials peut ensuite être utilisé pour obtenir un jeton d’accès à partir d’un script, puis ce jeton peut être mis en cache dans l’objet `global` pour être réutilisé afin d’améliorer les performances. L’API peut alors fournir un nombre restreint de points de terminaison protégés qui n’exécutent que les fonctions de gestion héritées requises (par exemple, `read user`, `change password`). Par défaut, Auth0 vous remettra un jeton pour n’importe quelle API si vous vous authentifiez avec succès et incluez l’audience appropriée. Restreindre l’accès à l’API du magasin d’identités hérité en limitant l’attribution des jetons d’accès au moyen d’une Rule empêchera toute utilisation non autorisée et atténuera plusieurs scénarios d’attaque, notamment lorsqu’une redirection vers `/authorize` est interceptée et que l’audience de l’API est ajoutée.
### Mettre en liste d’autorisation l’accès au stockage d’identités hérité
Que vous gériez l’accès à un magasin d’identités hérité au moyen d’une API personnalisée ou de l’interface native fournie, limitez l’accès à la liste des adresses IP associées à votre locataire Auth0. La mise en liste d’autorisation limite l’accès au magasin d’identités hérité et garantit que seuls les scripts d’Action de base de données personnalisés définis dans Auth0 sont autorisés. La liste d’autorisation d’adresses IP d’Auth0 est partagée entre tous les locataires Auth0 définis dans une même région. N’utilisez jamais la liste d’autorisation comme seule méthode pour sécuriser l’accès à votre magasin d’identités hérité; cela pourrait créer des vulnérabilités de sécurité et permettre un accès non autorisé à vos utilisateurs.
## Pour en savoir plus
* [Créer des connexions de base de données personnalisées](/fr-CA/docs/authenticate/database-connections/custom-db/create-db-connection) * [Modèles de scripts Action pour les bases de données personnalisées](/fr-CA/docs/authenticate/database-connections/custom-db/templates) * [Résoudre les problèmes liés aux bases de données personnalisées](/fr-CA/docs/authenticate/database-connections/custom-db/error-handling) * [Importer et exporter des utilisateurs](/fr-CA/docs/manage-users/user-migration)