Une directive générale pour migrer votre base de données utilisateur existante vers Logto
Cet article présente comment utiliser les outils existants pour migrer les données utilisateur précédentes vers Logto, dans la situation où Logto n'a pas encore fourni de services de migration de données.
Darcy YeDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Logto n'a pas encore une série d'outils pour la migration de données, mais nous avons ouvert les capacités de base de Management API. Cela n'empêchera pas les utilisateurs de compléter la migration des bases de données utilisateur existantes en écrivant des scripts.
En vue de certains des besoins reçus de la part des utilisateurs de la communauté, et du fait que nous n'avons pas actuellement de documentation expliquant les étapes spécifiques de la migration de la base de données utilisateur, nous faisons une introduction appropriée dans cet article pour aider les utilisateurs à trouver des idées spécifiques et à gagner du temps en lisant le code Logto et la documentation.
Étape 1 : Comprendre la structure de données utilisateur de base et le cas d'utilisation de Logto#
Logto utilise la base de données PostgreSQL au cœur de son système. Outre ses divers avantages en termes de performance, une raison importante est qu'il prend en charge le type de données JSON / JSONB personnalisé et permet de construire des indexations sur les valeurs internes des données de type JSON, équilibrant à la fois la performance de la base de données et l'extensibilité.
Pour la structure de données utilisateur de Logto, veuillez consulter la référence utilisateur pour comprendre tous les détails. Ici, nous nous concentrons sur la description de certains aspects où Logto peut être différent d'autres services d'identité.
Il s'agit d'un identifiant unique interne généré de façon aléatoire pour les utilisateurs de Logto. Les utilisateurs ne sont pas conscients de l’id lorsqu'ils utilisent des services basés sur Logto.
Les ingénieurs familiers avec les bases de données ne devraient pas trouver cela étrange. Même les systèmes d'identité les plus rudimentaires auront un id pour identifier unique les utilisateurs, bien que leurs formes diffèrent souvent. Certains services d'identité peuvent utiliser le nom d'utilisateur pour identifier de manière unique les utilisateurs.
Ici, le nom d'utilisateur, l'email principal, le téléphone principal sont des points où Logto diffère grandement des autres systèmes d'identité - ils peuvent tous servir d'identificateurs uniques perceptibles par l'utilisateur final.
Dans de nombreux autres systèmes d'identité, le nom d'utilisateur est utilisé pour l'identification (les noms d'utilisateur ne peuvent pas être dupliqués entre les comptes), ce qui est facile à comprendre.
Mais dans Logto, l'email principal / le téléphone sont également utilisés pour distinguer les utilisateurs. Autrement dit, si un utilisateur A a déjà l'email principal [email protected], alors les autres utilisateurs B ne peuvent pas ajouter cette adresse email comme leur email principal. Le téléphone principal fonctionne de la même manière.
Certains autres systèmes d'identité permettent d'enregistrer plusieurs comptes avec différents noms d'utilisateur mais en liant le même email / téléphone, ce qui n'est pas autorisé dans Logto (les emails / téléphones peuvent être ajoutés au customData de Logto). C'est parce que l'email principal / téléphone dans Logto peut être utilisé pour la connexion sans mot de passe.
Logto définit ce champ identités comme de type JSON, sa définition de type :
Ces dernières années, pour faciliter l'acquisition de nouveaux utilisateurs, les systèmes d'identité permettent aux utilisateurs de se connecter rapidement via certains comptes sociaux existants avec un grand nombre d'utilisateurs, tels que google / facebook, etc.
Dans l'exemple ci-dessous, le champ identités stocke les informations de connexion sociale :
Où facebook et github sont les noms des fournisseurs sociaux, userId est l'id du compte social de l'utilisateur utilisé pour se connecter. Les details incluent également d'autres informations que l'utilisateur a autorisées le fournisseur social à afficher, qui seront ajoutées au profil d'utilisateur Logto de l'utilisateur à des moments spécifiques.
Si la base de données précédente contient le nom (par exemple facebook , google) et l'id du fournisseur social utilisé par l'utilisateur (voir userId dans l'exemple précédent), alors l'utilisateur de Logto peut se connecter directement avec le même compte social.
Ce champ peut stocker toute information liée à l'utilisateur, comme les emails / téléphones mentionnés ci-dessus qui ne peuvent pas être utilisés pour la connexion sans mot de passe (peuvent être utilisés pour recevoir des notifications ou pour d'autres fonctions liées à l'entreprise), etc.
Les autres champs sont relativement faciles à comprendre (à l'exception de passwordEncrypted et passwordEncryptionMethod qui seront expliqués plus tard), veuillez lire vous-même la documentation.
Étape 2 : Rédaction de scripts de migration de base de données#
Pour une migration de base de données à grande échelle, la rédaction de scripts de migration est l'approche la plus courante. Nous fournirons un exemple simple pour aider à comprendre comment écrire des scripts de migration pour répondre à différents besoins.
Il convient de noter que lors de la rédaction de scripts de migration, nous omettons le processus de récupération des données originales, car il existe de nombreuses façons d'obtenir des données, telles que l'exportation de la base de données vers des fichiers puis la lecture des fichiers, ou la récupération par le biais d'APIs. Ce ne sont pas le cœur du script de migration, nous ne les discuterons donc pas en détail ici.
Lorsque vous voyez tenant_id dans le script de migration, vous pouvez le trouver étrange. Logto est basé sur une architecture multi-locataire. Pour les utilisateurs de Logto open source (Logto OSS), vous pouvez simplement définir le tenant_id de l'utilisateur sur default.
Pour les utilisateurs auto-hébergés de Logto OSS, la connexion à la base de données est facile à obtenir. Cependant, pour les utilisateurs du cloud Logto, pour des raisons de sécurité, nous ne pouvons actuellement pas fournir de permissions de connexion à la base de données aux utilisateurs. Les utilisateurs doivent se référer à la Documentation API et utiliser les API liées à l'Utilisateur pour migrer les utilisateurs. Nous comprenons que cette méthode n'est pas appropriée pour la migration de données utilisateur à grande échelle, mais peut encore gérer la migration d'un nombre limité d'utilisateurs à ce stade.
Étape 3 : Défi de la migration de mot de passe haché et solution potentielle#
Dans notre précédent blog, nous avons parlé de certaines mesures pour prévenir les attaques par mot de passe. Une chose que les fournisseurs d'infrastructures d'identité peuvent faire est de ne pas stocker les mots de passe en texte brut mais de sauvegarder les mots de passe hachés.
Un autre article de blog a expliqué les hachages de mot de passe, où nous avons affirmé que les valeurs de hachage sont irréversibles.
Le deuxième article de blog a également comparé l'évolution de certains algorithmes de hachage. Logto lui-même utilise l'algorithme Argon2i mentionné dans l'article et ne prend pas en charge d'autres algorithmes de hachage pour le moment. Cela signifie que les hachages de mots de passe des anciennes bases de données utilisateur utilisant d'autres algorithmes de hachage ne peuvent pas être directement migrés vers la base de données de Logto.
Même si Logto prend en charge d'autres algorithmes de hachage couramment utilisés en plus de Argon2i, il serait toujours difficile de migrer directement les anciennes données en raison de la flexibilité du sel lors de l'application des algorithmes de hachage.
En plus de prendre en charge d'autres algorithmes de hachage à l'avenir, Logto est également susceptible de fournir des méthodes de calcul d'empreinte personnalisées pour s'adapter à diverses situations.
Avant cela, vous pouvez utiliser la configuration de l'expérience de connexion de Logto pour permettre aux utilisateurs de se connecter par d'autres moyens (tels que l'email + le code de vérification) et de remplir un nouveau mot de passe (qui utilisera l'algorithme de hachage Argon2i) avant d'entrer dans l'application. Ensuite, le nouveau mot de passe peut être utilisé pour se connecter ultérieurement.
Il convient de noter que si les données utilisateur originales ne prennent en charge que la connexion avec un mot de passe, la solution de contournement mentionnée ci-dessus ne fonctionnera pas pour ce scénario. C'est parce que la solution de contournement mentionnée précédemment résout en fait le problème d'incompatibilité de hachage de mot de passe en utilisant des méthodes de connexion alternatives et en exploitant le mécanisme de "complétion d'information requise" dans le flux de fin d'utilisateur de Logto.
Donc, si seulement le login par mot de passe est supporté dans les données utilisateur originales, la solution de contournement ne peut pas résoudre cette situation, puisqu'il n'y a pas d'options de login alternatives disponibles.
La solution de contournement mentionnée ici ne résout pas vraiment le problème de la migration des mots de passe hachés, mais offre une solution alternative du point de vue du produit Logto pour éviter d'empêcher les utilisateurs de se connecter à votre produit.
Étape 4 : Passage graduel à Logto et surveillance de l'état#
Après avoir complété les étapes ci-dessus, les utilisateurs finaux peuvent déjà se connecter et utiliser votre service via Logto.
Comme le service n'est généralement pas interrompu pendant la migration, il est possible que les données utilisateur synchronisées avec Logto ne soient pas à jour. Lorsque de tels cas peu communs sont détectés, une synchronisation de l'ancienne base de données vers Logto doit être effectuée.
Après une plus longue période de temps (ou d'autres métriques définies peuvent être appliquées) sans la survenue de données incohérentes, l'ancienne base de données peut être complètement abandonnée.
Dans le post, nous avons présenté les étapes qu'une migration de base de données idéale traverserait.
Si vous rencontrez des problèmes non mentionnés ci-dessus, n'hésitez pas à rejoindre notre communauté ou à nous contacter pour de l'aide. Les problèmes que vous rencontrez pourraient également être rencontrés par d'autres, et deviendront des problèmes que nous devrons envisager lors de la conception des outils de migration à l'avenir.
