Arquitectura de microservicios: uso de Auth Server como servidor de recursos de usuario

9

Estoy diseñando una aplicación basada en la arquitectura de microservicios,

En esta aplicación necesitaré un microservicio de autenticación,

También tendré que almacenar información adicional del usuario, como, tal vez, múltiples direcciones, imagen de avatar, etc.

Esto lleva a la idea de tener dos microservicios, uno para Auth y otro, User, que podría almacenar información adicional del usuario,

Hasta ahora, tengo las siguientes ideas:

  1. Permitir que el servicio de autenticación también sea un servidor de recursos que contenga información del usuario, incluidas direcciones adicionales, tal vez, un avatar, etc. Esta es una solución conveniente porque permite tener todo lo relacionado con el usuario en un solo lugar y reduce la complejidad para operaciones como el registro de nuevos Usuario, eliminación de usuario. Sin embargo, esta solución parece contradecir el concepto de microservicios, pero para mí esta solución es la más atractiva.

  2. Tener dos microservicios diferentes: autenticación y usuario. Auth sería responsable solo del manejo de los tokens y no almacenará ningún dato relacionado con el Usuario. Entonces, cuando se recibe la solicitud de un token, el servicio de autenticación llama al Usuario para recibir los datos del Usuario y tomar una decisión

  3. Tener dos microservicios diferentes: autenticación y usuario. Auth sería responsable de manejar los tokens y también almacenar una parte de la información del usuario relacionada con la autenticación (tal vez contraseña, roles). El servicio de usuario mantendrá toda otra información, como direcciones adicionales, avatares, etc. Este enfoque para mí parece demasiado complejo porque requiere un usuario complejo para eliminar / crear nuevas operaciones de usuario

Ahora, tendré que elegir una de estas soluciones, pero estoy perdido y no estoy seguro de cuál es la correcta,

Apreciaré cualquier consejo con respecto a esto,

Gracias

design architecture microservices authentication Andrey Yaskulsky
fuente
1
# 3, felicitaciones, te has dado cuenta de que hay un elemento más en tu modelo. Cuenta . No sé por qué las personas se esfuerzan por vincular la seguridad contra los usuarios directamente cuando es evidente que la seguridad es un contexto limitado por sí mismo. Elimine los datos de seguridad de los Usuarios y su aplicación estará lista para cambiar el modelo de seguridad actual por cualquier otro, sin interferir con el dominio. Incluso es posible permitir más de un modelo de seguridad simplemente desacoplando estas 2 preocupaciones :-)
Laiv

Respuestas:

7

3 es la respuesta correcta.

Su servidor de autenticación autentica a los usuarios, su servidor de usuario podría ser mejor llamado 'UserProfiles'

Descubrirá que muchos de sus usuarios serán personas con perfiles, pero también tendrá usuarios de servicio para otras API o quizás claves de API simples, que también usan el servidor de autenticación para autenticar pero no tienen el perfil correspondiente.

Además, probablemente encontrará que hay muchos servidores y marcos de autenticación listos para usar que puede usar, pero su perfil de usuario se personalizará según sus necesidades. A menudo es más fácil agregar un useridperfil personalizado que integrar un perfil personalizado con una base de datos de autenticación prefabricada

Ewan
fuente