Микросервис аутентификации и микросервис пользователей. Должны ли быть они одним сервисом?
Логин и пароль прилетают в сервис аутентификации. Дальше, он должен отправить пост или гет запрос на сервис пользователей для определения корректности введённого пароля.
Тогда на сервисе аутентификации будет метод принимающий пару логин пароль. Логично. Дальше он должен обратиться к сервису пользователей с какими данными?
Джанго Всемогущий, да не нужно ему никуда обращаться. Вся суть микросервисной архитектуры в максимальной независимости и самостоятельности микросервисов. Клиентская часть, когда ей нужна аутентификация, отправляет на что-нибудь вроде https://auth.yourdomain.ru/login запрос с логином и паролем, микросервис ищет в БД запрошенный логин, сверяет хэш пароля, если правильный, отдаёт клиенту токен - всё.
Сергей Горностаев, вообщем как обычно. Ищем компромиссы. В теории истоки микросервисов уходят чуть ли не в отдельную бд для кажого сервиса.
В моем текущем варианте, пароль логин храниться в строке пользователя. Поэтому и сервис аутентификации и сервис пользователей работает с одной бд. Я думаю сделать из двух один.
Хотя хотелось бы их разделить, не трогая бд. Тогда после получения пары логин пароль на СА, мы должны получить пользователя по логину из СП и чекнуть пароль.
аутентификация пользователя происходит в микросервисы пользователей, выдача токенов авторизации может происходить на другом микросервисе.
Авторизовывать можно не только пользователей, но и другие приложения (если запрос например бэкенд - бэкенд).
есть такой подход: посмотреть на сколько пересекаются сущности с которыми приходится работать, и специфичная для работы терминология - мне кажется что тут полное пересечение до степени смешения - поэтому я бы делал как один сервис.