Разделение сервера авторизации OAuth2 и сервера ресурсов - PullRequest
Новая
       40

Разделение сервера авторизации OAuth2 и сервера ресурсов

0 голосов
/ 12 июня 2019

Я использую сервер авторизации OAuth2 и сервер ресурсов.

и там много документов сказано мне «Сервер авторизации и сервер ресурсов могут быть разделены или нет»

Мне нравится MSA, поэтому я решил разделить эти серверы.

Я видел много документов в Интернете по этому вопросу, но на практике я больше не могу.

Я использую SpringBoot2.

  • Сценарий
    1. Пользователь подключен к моему Client приложению.
    2. Запрос к защищенной конечной точке /client/me
    3. в контроллере Client, если пользователь не прошел аутентификацию, перенаправить на конечную точку входа Authorization Server /auth/oauth/authorize.
    4. если пользователь сначала заходит в мое Client приложение, он будет входить (не входить) в мой Authorization Server.
    5. на странице регистрации Authorization Server пользователь введет свои username, realusername, password и email.
    6. Учетная запись пользователя выдана, и пользователь войдет в систему через мою Authorization Server форму входа.
    7. в случае успешного входа в систему Client запросит конечную точку Resource Server /me с access-token, а контроллер Resource Server, сопоставленный с /me, вернет объект Principal или Authentication как REST API.
    8. Client свяжет там результаты REST API с DefaultOAuth2User или CustomOAuth2User по моему SecurityContext.

вот вопрос.

Насколько я знаю, конечная точка Resource Server /me будет предоставлять ресурсы пользователя. например, настоящее имя или адрес электронной почты и т. д.

но пользователь зарегистрировался в Authorization Server, поэтому вся информация сохраняется в базе данных Authorization Server.

мои серверы oauth2 MSA. поэтому БД тоже была отделена.

тогда, как я могу установить email или realname на Principal, или Authentication, или CustomOAuth2User Объект через Resource Server s /me конечную точку?

1 Ответ

1 голос
/ 13 июня 2019

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

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

Чтобы ответить на ваш вопрос, вы можете создать контроллеры на сервере ресурсов, который предоставляет регистрацию, и другиефункциональные возможности.Затем этот сервер будет звонить на сервер авторизации.Для регистрации Resource Server передает учетные данные на Auth Server, чтобы узнать, было ли имя пользователя уже заявлено, и если не зарегистрировать пользователя и на основании ответа Auth Server, Resource Server продолжит регистрацию пользователя.Для входа в систему веб-интерфейс может напрямую обратиться к серверу аутентификации для получения токена.

Для всех последующих вызовов к защищенным ресурсам (с токеном доступа) серверу ресурсов потребуется вызвать сервер аутентификации для проверки токенов.Для этого Spring предоставляет CheckTokenEndpoint (/oauth/check_token).

Вы также можете проверить OAuth2RestTemplate .Это может быть использовано на сервере ресурсов для выполнения запросов REST к серверу аутентификации.Обратите внимание, что Resource Server (или любое другое внутреннее приложение, которое у вас есть, например, веб-интерфейс) будет клиентом для Auth Server.Им также нужно будет аутентифицироваться и авторизоваться.

...