Arquitetura de microsserviço - usando o servidor de autenticação como um servidor de recursos do usuário

Estou projetando um aplicativo baseado na arquitetura de microsserviços,

Nesta aplicação, precisarei do microserviço de autenticação,

Também precisarei armazenar algumas informações extras do usuário, como, talvez, vários endereços, imagem de avatar etc.

Isso leva à ideia de ter dois microsserviços - um para Auth e outro, User, que pode armazenar informações extras do usuário,

Até agora, tenho as seguintes idéias:

Permitir que o serviço de autenticação também seja um servidor de recursos que conteria informações do usuário, incluindo endereços adicionais, talvez um avatar etc. Usuário, excluindo Usuário. No entanto, essa solução parece contradizer o conceito de microsserviços, mas quanto a mim, essa solução é a mais atraente.
Tendo dois microsserviços diferentes - Auth e User. O Auth seria responsável apenas pelo tratamento de tokens e não armazenará nenhum dado relacionado ao Usuário. Portanto, quando a solicitação de um token é recebida, o serviço de autenticação chama o usuário para receber dados do usuário e tomar uma decisão
Tendo dois microsserviços diferentes - Auth e User. O Auth seria responsável por manipular os tokens e também armazenar parte das informações do usuário relacionadas à autenticação (talvez senha, funções). O serviço do usuário manterá todas as outras informações, como endereços adicionais, avatares, etc. Essa abordagem para mim parece muito complexa porque requer uma exclusão complexa do usuário / criação de novas operações do usuário

Agora, precisarei escolher uma dessas soluções, mas estou perdido e não tenho certeza qual delas é a correta,

Apreciará qualquer conselho com relação a isso,

obrigado

— Andrey Yaskulsky
fonte

# 3, parabéns, você percebeu que há mais um elemento no seu modelo. Conta . Não sei por que as pessoas se esforçam para vincular a segurança diretamente aos usuários quando é evidente que a segurança é um contexto limitado por si próprio. Decuple os dados de segurança de Usuários e seu aplicativo estará pronto para alterar o modelo de segurança atual por qualquer outro, sem mexer no domínio. Mesmo tendo mais de um modelo de segurança é possível apenas ser desacoplamento estes 2 preocupações :-)

— LAIV

3 é a resposta correta.

Seu servidor de autenticação autentica os usuários. Talvez o servidor de seu usuário seja melhor denominado 'UserProfiles'

Você verá que muitos de seus usuários serão pessoas com perfis, mas também terá usuários de serviço para outras APIs ou talvez chaves simples de API, que também usam o servidor de autenticação para autenticar, mas não têm perfil correspondente.

Além disso, você provavelmente descobrirá que existem muitos servidores e estruturas de autenticação prontos para usar, mas o UserProfile será personalizado de acordo com suas necessidades. Geralmente, é mais fácil adicionar um userida um perfil personalizado do que integrar um perfil personalizado a um banco de dados de autenticação pré-fabricado

— Ewan
fonte