Uma orientação geral para migrar a sua base de dados de utilizadores existente para o Logto

O Logto ainda não possui uma série de ferramentas para migração de dados, mas abrimos as capacidades básicas da Management API. Isso não impedirá os usuários de concluir a migração das bases de dados de utilizadores existentes por meio da escrita de scripts.

Tendo em vista algumas das necessidades recebidas dos utilizadores da comunidade, e o fato de que atualmente não temos documentação explicando os passos específicos da migração da base de dados do utilizador, fazemos uma introdução adequada neste artigo para ajudar os utilizadores a encontrar idéias específicas e economizar tempo lendo o código Logto e a documentação.

Passo 1: Entender a estrutura básica dos dados do utilizador Logto e o caso de uso#

O Logto usa a base de dados PostgreSQL debaixo do capô. Além das diversas vantagens de performance, um motivo importante é que ele suporta o tipo de dados JSON/JSONB personalizado e permite a construção de indexação em valores internos de dados digitados em JSON, equilibrando tanto a performance da base de dados quanto a expansibilidade.

Para a estrutura de dados do utilizador do Logto, por favor consulte a referência do utilizador para entender todos os detalhes. Aqui focamos em descrever alguns aspetos onde o Logto pode ser diferente de outros serviços de identidade.

id#

Este é um identificador único interno gerado aleatoriamente para utilizadores do Logto. Os utilizadores não têm conhecimento de id ao usar serviços baseados em Logto.

Engenheiros familiarizados com base de dados não devem achar isto estranho. Mesmo os sistemas de identidade mais rudimentares terão um id para identificar de forma única os utilizadores, embora as suas formas sejam frequentemente diferentes. Alguns serviços de identidade podem usar o nome de utilizador para identificar de forma única os utilizadores.

username, primaryEmail, primaryPhone#

Aqui, o nome do utilizador, o e-mail principal, o telefone principal são onde o Logto difere muito de outros sistemas de identidade - todos eles podem servir como identificadores únicos perceptíveis ao utilizador final.

Em muitos outros sistemas de identidade, o nome do utilizador é usado para identificação (os nomes de utilizador não podem ser duplicados entre as contas), o que é fácil de ser entendido.

Mas no Logto, o e-mail/telefone principal também é usado para distinguir os utilizadores. Ou seja, se o utilizador A já tiver o e-mail principal [email protected], então outros utilizadores B não podem adicionar este endereço de e-mail como o seu e-mail principal. O telefone principal funciona de forma semelhante.

Alguns outros sistemas de identidade permitem o registo de várias contas com nomes de utilizador diferentes, mas vinculam o mesmo e-mail/telefone, o que não é permitido no Logto (e-mails/telefones podem ser adicionados aos dadosPersonalizados do Logto). Isso ocorre porque o e-mail/telefone principal no Logto pode ser usado para iniciar sessão sem senha.

identidades#

O Logto define este campo identities como tipo JSON, a sua definição de tipo:

Nos últimos anos, para facilitar a obtenção de novos utilizadores, os sistemas de identidade permitem que os utilizadores iniciem sessão rapidamente através de algumas contas sociais existentes com uma grande base de utilizadores, como google / facebook, etc.

No exemplo abaixo, o campo identities armazena informações de login social:

Onde facebook e github são os nomes dos fornecedores sociais, userId é o id da conta social do utilizador usada para iniciar sessão. Os detalhes também incluem alguma outra informação que o utilizador autorizou o fornecedor social a exibir, que será adicionada ao perfil do utilizador Logto do utilizador em momentos específicos.

Se a base de dados anterior contém o nome (ex. facebook, google) e id do fornecedor social utilizado pelo utilizador (veja userId no exemplo anterior), então o utilizador Logto pode iniciar sessão diretamente com a mesma conta social.

dadosPersonalizados#

Este campo pode armazenar qualquer informação relacionada ao utilizador, como e-mails/telefones mencionados acima que não podem ser usados para iniciar sessão sem senha (podem ser usados para receber notificações ou para outras funções relacionadas aos negócios), etc.

Outros campos são relativamente fáceis de compreender (exceto por senhaCriptografada e métodoDeCriptografiaDeSenha que serão explicados mais tarde), por favor leia a documentação você mesmo.

Passo 2: Escrevendo scripts de migração de base de dados#

Para uma migração de base de dados em larga escala, escrever scripts de migração é a abordagem mais comum. Vamos fornecer um exemplo simples para ajudar a entender como escrever scripts de migração para atender a diferentes necessidades.

Deve-se notar que ao escrever scripts de migração, saltamos o processo de recuperação dos dados originais, porque existem muitas maneiras de obter dados, como exportar da base de dados para arquivos e depois ler os arquivos, ou recuperar por meio de APIs. Estes não são o foco do script de migração, então não discutiremos eles em detalhe aqui.

Quando você vê tenant_id no script de migração, você pode achar estranho. Logto é baseado numa arquitetura multi-tenant. Para utilizadores Logto de código aberto (Logto OSS), você pode apenas definir o tenant_id do utilizador para default.

Para utilizadores auto-hospedados do Logto OSS, a conexão da base de dados é fácil de obter. No entanto, para os utilizadores da nuvem Logto, por razões de segurança, atualmente não podemos fornecer permissões de conexão da base de dados aos utilizadores. Os utilizadores precisam referir-se à API Docs e usar as APIs relacionadas ao Utilizador para migrar utilizadores. Compreendemos que este método não é apropriado para uma grande migração de dados do utilizador, mas pode ainda lidar com a migração de um número limitado de utilizadores neste estágio.

Passo 3: Desafio da migração de senha hash e solução potencial#

No nosso blogue anterior, falamos sobre algumas medidas para prevenir ataques de senha. Uma coisa que os provedores de infraestrutura de identidade podem fazer é não armazenar senhas em texto simples, mas guardar senhas hash.

Outro post no blog explicou os hashes de senha, onde afirmamos que os valores hash são irreversíveis.

O segundo post no blog também comparou a evolução de alguns algoritmos de hashing. O próprio Logto usa o algoritmo Argon2i mencionado no artigo e não suporta outros algoritmos hash por enquanto. Isso significa que hashes de senha de bases de dados de utilizadores antigas usando outros algoritmos de hashing não podem ser diretamente migradas para a base de dados do Logto.

Mesmo que Logto suporte outros algoritmos de hash comumente usados além de Argon2i, ainda seria difícil migrar diretamente os dados antigos devido à flexibilidade do salt ao aplicar algoritmos de hashing.

Além de suportar outros algoritmos de hashing no futuro, Logto também pode fornecer métodos de cálculo de salt personalizados para se adaptar a várias situações.

Antes disso, você pode usar a [configuração da experiência de login] do Logto(https://docs.logto.io/docs/recipes/customize-sie/) para permitir que os utilizadores iniciem sessão por meio de outras maneiras (como e-mail + código de verificação) e preencham uma nova senha (que usará o algoritmo de hashing Argon2i) antes de entrar no aplicativo. Então a nova senha pode ser usada para iniciar sessão mais tarde.

Deve-se notar que se os dados do utilizador original suportam apenas início de sessão com uma senha, a solução mencionada acima não funcionará para este cenário. Isto ocorre porque a solução mencionada anteriormente, na verdade, resolve o problema de incompatibilidade de hash de senha, usando métodos alternativos de início de sessão e aproveitando o mecanismo de "completude de informações necessárias" no fluxo do utilizador final do Logto.

Portanto, se apenas o login com senha é suportado nos dados do utilizador original, a solução alternativa não pode resolver esta situação, já que não há opções de login alternativas disponíveis.

A solução alternativa mencionada aqui não resolve realmente o problema da migração de senha hash, mas fornece uma solução alternativa do ponto de vista do produto Logto para evitar impedindo os utilizadores de iniciar sessão em seu produto.

Passo 4: Mudança gradual para o Logto e monitoramento do estado#

Após concluir os passos acima, os utilizadores finais já podem iniciar sessão e usar o seu serviço através do Logto.

Como o serviço geralmente não é cortado durante a migração, é possível que os dados do utilizador sincronizados com o Logto não estejam atualizados. Quando tais casos incomuns são detectados, a sincronização da base de dados antiga para o Logto precisa ser realizada.

Após um período de tempo mais longo (ou outras métricas definidas podem ser aplicadas) sem a ocorrência de dados inconsistentes, a base de dados antiga pode ser completamente abandonada.

Conclusão#

No post, apresentamos os passos que uma migração de base de dados ideal passaria.

Se você se deparar com problemas não mencionados acima, não hesite em se juntar à nossa comunidade ou nos contactar por ajuda. Os problemas que encontra podem também ser encontrados por outros, e se tornarão questões que precisamos considerar ao projetar ferramentas de migração no futuro.