Как обрабатывать регистрацию пользователей на сервере OAuth, когда он отделен от сервера ресурсов?

Question

Я работаю над приложением, в котором пользователи с повышенными ролями (администраторы) могут создавать других пользователей (с более низкими ролями). Я использую PHP (Slim Framework) и MySQL.

Пока у меня есть сервер ресурсов, доступ к которому можно получить через API REST с токенами доступа, полученными с сервера OAuth с использованием пароля. Два сервера имеют отдельные базы данных. Существует также веб-сервер, который предоставляет панель управления, на которой администраторы входят в систему и создают новых пользователей, устанавливая их имя пользователя, пароль и другую общую информацию.

Учитывая тот факт, что как Ресурс-сервер, так и OAuth-сервер должны хранить пользовательские данные в соответствующих таблицах БД, было бы хорошо, если бы Ресурс-сервер по запросу нового пользователя сохранял общую информацию о пользователях в своих «пользователях». "table AND отправляет запрос с учетными данными пользователя на OAuth-сервер, который добавит новую запись в свою таблицу" oauth_users "? Если нет, то каков наилучший и безопасный способ достижения этой функциональности?

Заранее спасибо!

Answer 1

Этот подход работает для нас.

На стороне Auth Server db необходимо хранить только: настроенный идентификатор пользователя, URL-адреса перенаправления и авторизованный уровень обслуживания (области); предоставленные токены доступа; и другие авторизация необходимые данные (роли в вашем случае).

Сервер входа в систему db, хранит: идентификатор пользователя, пароль и другие аутентификация связанные данные.

Служба пользовательских ресурсов (обычно это RESTFul API) должна хранить: идентификатор пользователя и другие личные данные .

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

В общем, я лично использую принцип DRY с такой архитектурой.

Ура!