Una guía general para migrar tu base de datos de usuarios existente a Logto

Logto aún no tiene una serie de herramientas para la migración de datos, pero hemos abierto las capacidades básicas de Management API. Esto quiere decir que los usuarios podrán completar la migración de las bases de datos de usuarios existentes a través de la escritura de scripts.

Con respecto a algunas de las necesidades recibidas de los usuarios de la comunidad, y el hecho de que actualmente no tenemos documentación que explique los pasos específicos de la migración de bases de datos de usuarios, realizamos una introducción apropiada en este artículo para ayudar a los usuarios a encontrar ideas específicas y ahorrar tiempo en la lectura de código y documentación de Logto.

Paso 1: Comprender la estructura de datos de usuario básica de Logto y el caso de uso#

Logto utiliza la base de datos PostgreSQL en su interior. Además de sus diversas ventajas en rendimiento, una razón importante es que soporta el tipo de dato personalizado JSON / JSONB y permite que se construyan índices en valores internos de los datos tipados JSON, equilibrando tanto rendimiento como extensibilidad de la base de datos.

Para la estructura de datos de usuario de Logto, por favor refiérase a la referencia de usuario para entender todos los detalles. Aquí nos centraremos en describir algunos aspectos que pueden distinguir Logto de otros servicios de identidad.

id#

Este es un identificador único interno generado aleatoriamente para los usuarios de Logto. Los usuarios desconocen el id cuando utilizan servicios basados en Logto.

Los ingenieros familiarizados con las bases de datos no deberían encontrar esto extraño. Incluso los sistemas de identidad más rudimentarios tendrán un id para identificar de manera única a los usuarios, aunque sus formas a menudo difieren. Algunos servicios de identidad pueden usar el nombre de usuario para identificar de manera única a los usuarios.

username, primaryEmail, primaryPhone#

Aquí, el nombre de usuario, el correo electrónico primario y el teléfono primario son donde Logto difiere en gran medida de otros sistemas de identidad - todos pueden funcionar como identificadores únicos percibidos por el usuario final.

En muchos otros sistemas de identidad, se utiliza el nombre de usuario para la identificación (los nombres de usuario no pueden ser duplicados entre cuentas), lo que es fácil de entender.

Pero en Logto, el correo electrónico primario y el teléfono también se utilizan para distinguir a los usuarios. Es decir, si un usuario A ya tiene el correo electrónico primario [email protected], entonces otros usuarios B no podrán añadir esta dirección de correo electrónico como su correo electrónico primario. El teléfono primario funciona de manera similar.

Algunos otros sistemas de identidad permiten registrar múltiples cuentas con diferentes nombres de usuario pero vinculando el mismo correo electrónico/teléfono, lo cual no está permitido en Logto (los correos electrónicos/teléfonos pueden ser añadidos a los customData de Logto). Esto se debe a que el correo electrónico/ teléfono primario en Logto pueden ser utilizados para el inicio de sesión sin contraseña.

identities#

Logto define este campo identities como de tipo JSON, su definición de tipo:

En los últimos años, para facilitar la adquisición de nuevos usuarios, los sistemas de identidad permiten a los usuarios iniciar sesión rápidamente a través de algunas cuentas sociales existentes con una gran base de usuarios, como google / facebook, etc.

En el ejemplo a continuación, el campo identities almacena información de inicio de sesión social:

Donde facebook y github son los nombres de los proveedores sociales, userId es el id utilizado para el inicio de sesión de la cuenta social del usuario. Los details también incluyen alguna otra información que el usuario ha autorizado al proveedor social a mostrar, que se agregará al perfil de usuario de Logto en momentos específicos.

Si la base de datos anterior contiene el nombre (por ejemplo, facebook, google) y el id del proveedor social utilizado por el usuario (ver userId en el ejemplo anterior), entonces el usuario de Logto puede iniciar sesión directamente con la misma cuenta social.

customData#

Este campo puede almacenar cualquier información relacionada con el usuario, como correos electrónicos/teléfonos mencionados anteriormente que no puedan ser utilizados para iniciar sesión sin contraseña (pueden ser utilizados para recibir notificaciones o para otras funciones relacionadas con el negocio), etc.

Los otros campos son relativamente fáciles de entender (excepto passwordEncrypted y passwordEncryptionMethod que serán explicados más adelante), por favor lea la documentación por su cuenta.

Paso 2: Redacción de scripts de migración de bases de datos#

Para la migración de bases de datos a gran escala, la redacción de scripts de migración es el enfoque más común. Proporcionaremos un ejemplo simple para ayudar a entender cómo escribir scripts de migración para satisfacer diferentes necesidades.

Debe tenerse en cuenta que al escribir scripts de migración, omitimos el proceso de recuperación de los datos originales, porque hay muchas formas de obtener datos, como exportarlos de la base de datos a archivos, luego leer los archivos o recuperarlos a través de APIs. Estos no son el foco del script de migración, por lo que no los discutiremos en detalle aquí.

Cuando ves tenant_id en el script de migración, puedes encontrarlo extraño. Logto se basa en una arquitectura multitenant. Para los usuarios de Logto open source (Logto OSS), puedes simplemente configurar el tenant_id del usuario a default.

Para los usuarios auto alojados de Logto OSS, la conexión a la base de datos es fácil de obtener. Sin embargo, para los usuarios de la nube de Logto, por razones de seguridad, actualmente no podemos proporcionar permisos de conexión a la base de datos a los usuarios. Los usuarios necesitan referirse a la API Docs y utilizar las APIs relacionadas con el usuario para migrar usuarios. Entendemos que este método no es adecuado para la migración de datos de usuario a gran escala, pero aún puede manejar la migración de un número limitado de usuarios en esta etapa.

Paso 3: Desafío de la migración de las contraseñas cifradas y posible solución alternativa#

En nuestro anterior blog, hablamos sobre algunas medidas para prevenir ataques de contraseñas. Una cosa que los proveedores de infraestructura de identidad pueden hacer es no almacenar contraseñas en texto plano, sino guardar contraseñas cifradas.

Otra publicación del blog explicó las contraseñas hash, en la que afirmamos que los valores de hash son irreversibles.

El segundo post del blog también comparó la evolución de algunos algoritmos de hash. Logto en sí utiliza el algoritmo Argon2i mencionado en el artículo y no soporta otros algoritmos de hash por ahora. Esto significa que los hash de contraseñas de bases de datos de usuarios antiguos utilizando otros algoritmos de hash no pueden migrarse directamente a la base de datos de Logto.

Incluso si Logto soporta otros algoritmos de hash comúnmente utilizados, además de Argon2i, seguiría siendo difícil migrar directamente los datos antiguos debido a la flexibilidad de la sal al aplicar algoritmos de hash.

Además de soportar otros algoritmos de hash en el futuro, Logto también es probable que proporcione métodos de cálculo de sal personalizados para adaptarse a diversas situaciones.

Antes de eso, puedes utilizar la configuración de experiencia de inicio de sesión de Logto para permitir a los usuarios iniciar sesión a través de otras formas (como correo electrónico + código de verificación) y llenar una nueva contraseña (que utilizará el algoritmo de hash Argon2i) antes de entrar en la aplicación. Luego, la nueva contraseña podrá ser utilizada para iniciar sesión más tarde.

Debería observarse que si los datos originales del usuario solo admiten el inicio de sesión con una contraseña, la solución anterior no funcionará para este escenario. Esto se debe a que la solución mencionada antes de hecho resuelve el problema de la incompatibilidad de las contraseñas hash mediante el uso de métodos de inicio de sesión alternativos y aprovechando el mecanismo de "finalización de información requerida" en el flujo de usuario final de Logto.

Entonces, si solo se admitía el inicio de sesión con contraseña en los datos originales del usuario, no se puede resolver situación, ya que no hay opciones de inicio de sesión alternativas disponibles.

La solución alternativa mencionada aquí no resuelve realmente el problema de la migración de las contraseñas hash, sino que proporciona una solución alternativa desde la perspectiva del producto Logto para evitar que los usuarios se vean impedidos de ingresar a tu producto.

Paso 4: Cambio gradual a Logto y monitoreo de estado#

Después de completar los pasos anteriores, los usuarios finales ya pueden iniciar sesión y usar tu servicio a través de Logto.

Como el servicio generalmente no se interrumpe durante la migración, es posible que los datos de los usuarios sincronizados a Logto no estén actualizados. Cuando se detecten tales casos poco comunes, se necesita efectuar la sincronización de la base de datos antigua a Logto.

Después de un período de tiempo más largo (o se pueden aplicar otras métricas definidas) sin la ocurrencia de datos inconsistentes, la base de datos antigua puede ser completamente abandonada.

Conclusión#

En el post, presentamos los pasos que una migración ideal de base de datos atravesaría.

Si te encuentras con problemas que no se mencionaron anteriormente, no dudes en unirte a nuestra comunidad o contactarnos para ayudarte. Los problemas que encuentres también pueden ser encontrados por otros, y se convertirán en asuntos que necesitamos considerar al diseñar herramientas de migración en el futuro.