Uma orientação geral para migrar seu banco de dados de usuários existente para o Logto

Logto ainda não tem uma série de ferramentas para migração de dados, mas abrimos as capacidades básicas da API de Gestão. Isso não impede os usuários de completar a migração dos bancos de dados de usuários existentes escrevendo scripts.

Em vista de algumas das necessidades recebidas dos usuários da comunidade, e o fato de que atualmente não temos documentação explicando os passos específicos da migração do banco de dados do usuário, fazemos uma introdução adequada neste artigo para ajudar os usuários a encontrar ideias específicas e economizar tempo lendo o código Logto e documentação.

Passo 1: Compreender a estrutura básica de dados do usuário do Logto e o caso de uso#

Logto usa banco de dados PostgreSQL em seu núcleo. Além de suas várias vantagens de desempenho, um motivo importante é que ele suporta o tipo de dados JSON / JSONB personalizado e permite que o índice seja construído em valores internos de dados tipados JSON, equilibrando o desempenho e a extensibilidade do banco de dados.

Para a estrutura de dados do usuário do Logto, consulte a referência do usuário para entender todos os detalhes. Aqui nos concentramos em descrever alguns aspectos em que Logto pode ser diferente de outros serviços de identidade.

id#

Este é um identificador único interno gerado aleatoriamente para usuários do Logto. Os usuários desconhecem o id ao usar os serviços baseados no Logto.

Engenheiros familiarizados com bancos de dados não devem achar isso estranho. Até mesmo os sistemas de identidade mais rudimentares terão um id para identificar exclusivamente os usuários, embora suas formas geralmente variem. Alguns serviços de identidade podem usar o nome de usuário para identificar exclusivamente os usuários.

nome de usuário, email primário, telefone primário#

Aqui, nome de usuário, email primário, telefone primário são onde Logto difere muito de outros sistemas de identidade - todos podem servir como identificadores únicos perceptíveis pelo usuário final.

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

Mas em Logto, o e-mail / telefone primários também são usados para distinguir usuários. Ou seja, se o usuário A já tiver o e-mail primário [email protected], então outros usuários B não podem adicionar este endereço de e-mail como seu e-mail primário. O telefone primário funciona de maneira semelhante.

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

identidades#

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

Nos últimos anos, para facilitar a aquisição de novos usuários, os sistemas de identidade permitem que os usuários façam login rapidamente por meio de algumas contas sociais existentes com grande base de usuários, 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 provedores sociais, userId é o id da conta social do usuário usada para login. Os details também incluem algumas outras informações que o usuário autorizou o provedor social a exibir, que serão adicionadas ao perfil de usuário do Logto em momentos específicos.

Se o banco de dados anterior contém o nome (por exemplo, facebook, google) e id do provedor social usado pelo usuário (veja o userId no exemplo anterior), então o usuário do Logto pode fazer login diretamente com a mesma conta social.

customData#

Este campo pode armazenar qualquer informação relacionada ao usuário, como emails / telefones mencionados acima que não podem ser usados para login sem senha (podem ser usados para receber notificações ou para outras funções de negócios relacionadas), etc.

Outros campos são relativamente fáceis de entender (exceto passwordEncrypted e passwordEncryptionMethod que serão explicados mais tarde), por favor, leia a documentação você mesmo.

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

Para a migração de banco de dados em grande escala, a escrita de 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 diferentes necessidades.

Deve ser notado que, ao escrever scripts de migração, ignoramos o processo de recuperação dos dados originais, porque existem muitas maneiras de obter dados, como exportar do banco de dados para arquivos e depois ler os arquivos, ou recuperar por APIs. Esses não são o foco do script de migração, então não vamos discuti-los em detalhes aqui.

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

Para usuários do Logto OSS auto-hospedados, a conexão do banco de dados é fácil de obter. No entanto, para usuários do Logto na nuvem, por razões de segurança, atualmente não podemos fornecer permissões de conexão do banco de dados para os usuários. Os usuários precisam se referir à API Docs e usar os APIs relacionados ao usuário para migrar usuários. Entendemos que este método não é adequado para a migração de dados de usuários em grande escala, mas ainda pode lidar com a migração de um número limitado de usuários nesta fase.

Passo 3: Desafio de migração de senha hasheada e possível solução alternativa#

Em nosso blog anterior blog, 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 salvar senhas hasheadas.

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

A segunda postagem do blog também comparou a evolução de alguns algoritmos de hash. Logto em si usa o algoritmo Argon2i mencionado no artigo e não suporta outros algoritmos de hash por enquanto. Isso significa que as hashes de senha dos bancos de dados de usuários antigos que usam outros algoritmos de hashing não podem ser migrados diretamente para o banco de dados Logto.

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

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

Antes disso, você pode usar a configuração de experiência de logon do Logto sign-in experience configuration para permitir que os usuários façam login por outros meios (como email + código de verificação) e preencha uma nova senha (que usará o algoritmo de hashing Argon2i) antes de entrar no aplicativo. Então a nova senha pode ser usada para fazer o login mais tarde.

Deve-se notar que se os dados do usuário original apenas suportam o login com uma senha, o workaround mencionado acima não funcionará para este cenário. Isso ocorre porque a solução alternativa mencionada anteriormente resolve o problema de incompatibilidade de hash de senha usando métodos alternativos de login e aproveitando o mecanismo de "completamento de informações obrigatórias" no fluxo do usuário final do Logto.

Portanto, se apenas o login com senha for suportado nos dados do usuário original, a solução alternativa não pode resolver esta situação, uma vez que não existem opções alternativas de login disponíveis.

A solução alternativa mencionada aqui não resolve realmente o problema de migração de senha hasheada, mas fornece uma solução alternativa do ponto de vista do produto Logto para evitar que os usuários fiquem impedidos de acessar seu produto.

Passo 4: Mudança gradual para o Logto e monitoramento de status#

Após a conclusão das etapas acima, os usuários finais já podem fazer login e usar seu serviço por meio do Logto.

Como o serviço geralmente não é cortado durante a migração, é possível que os dados do usuário sincronizados com o Logto não estejam atualizados. Quando tais casos incomuns são detectados, é necessário realizar a sincronização do banco de dados antigo para o Logto.

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

Conclusão#

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

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