Авторизация и настройка пользовательских микросервисов

Я пытаюсь создать микросервис из существующего приложения с довольно стандартным управлением пользователями: имеет аутентификацию и авторизацию и сохраняет пользовательские данные.

Я разрабатываю сервер авторизации для управления аутентификацией и авторизации с помощью OAuth2 в качестве авторизации. С другой стороны я должен хранить информацию пользователя/профиль.

Вопрос: Если сервер авторизации управляется:

как авторизация, так и пользовательский API. Таким образом, другие микросервисы могут обращаться к серверу авторизации на /me, чтобы получить текущего пользователя, а также /users, чтобы получить полный список пользователей.
Или только авторизация, и я должен создать пользовательские микросервисы? Таким образом, сервер авторизации предоставляет только /me API, связанный с пользователем, и пользовательские микросервисы будут выставлять /users?

Первое решение немного проще, но сервер авторизации станет менее общим (менее многократно используется), поскольку модель данных пользовательских приложений будет его частью (модель данных базы данных таблицы User).

Другое требование Сервер авторизации должен проверить, существует ли пользователь перед его авторизацией.

Пользователь не создает автосоздание, пользователи должны быть приглашены администратором для доступа. С этим требованием первое решение прост, потому что сервер авторизации имеет доступ к пользовательской базе данных, но второе решение. Сервер авторизации подразумевает:

Поделиться базой данных с сервисом пользователя (гул не нравится)
Вызов службы пользователя перед авторизацией с использованием REST API (например)
Сервер авторизации должен поддерживать минимальную таблицу User (может быть переименован Account), и администратор не будет создавать пользователя в службе пользователя, а только учетную запись пользователя на сервере авторизации

Я думаю, что решение 1. отсутствует, но любые советы о 2. и 3.?

3. на первый взгляд кажется лучшим, но если я хочу перейти на другой сервер авторизации, например, публичный (OAuth2), такой как Google, Github, Facebook и т.д.... может быть компромиссным, потому что мы не можем контролировать создание учетной записи пользователя.

Любая обратная связь?

Ответ 1

Несколько вариантов здесь, поэтому, пожалуйста, предоставьте более подробную информацию. например Можете ли вы использовать готовую версию сервера авторизации (с открытым исходным кодом)? На какой технологии вы работаете?

Мне удалось легко интегрировать IdentityServer (https://github.com/IdentityServer/IdentityServer3) и подключить его к собственной службе "пользователи" с простой реализацией нескольких интерфейсы. Он также может обрабатывать ваши работы с БД (хранить все данные для OAuth 2.0, например, клиенты с секретами, коды auth и т.д.). IdentityServer позволяет вам предоставить свою собственную ссылку, чтобы иметь доступную для пользователя операцию регистрации, вы также можете иметь возможность Администратора принимать или отклонять регистрацию, поэтому только зарегистрированные пользователи смогут войти в систему.

В целом - реализация службы авторизации, как это требуется RFC для OAuth2.0 (подробности см. https://tools.ietf.org/html/rfc6749) никогда не является частью кекс. Вместо этого используйте проверенное решение.

Привет!