Как обрабатывать регистрацию пользователя на сервере OAuth, когда он отделен от сервера ресурсов?
Я работаю над приложением, в котором пользователи с повышенными ролями (администраторы) могут создавать других пользователей (с более низкими ролями). Я использую PHP (Slim framework) и MySQL.
Пока у меня есть сервер ресурсов, к которому можно получить доступ через REST API с токенами доступа, полученными с сервера OAuth с помощью предоставления пароля. Два сервера имеют отдельные базы данных. Существует также веб-сервер, который предоставляет панель управления, на которой администраторы входят в систему и создают новых пользователей, устанавливая их имя пользователя, пароль и другую общую информацию.
Учитывая тот факт, что и сервер ресурсов, и сервер OAuth должны хранить пользовательские данные в своих соответствующих таблицах базы данных, было бы нормально, если бы сервер ресурсов по запросу нового пользователя сохранял общую информацию о пользователе в своей таблице «пользователей» И отправляет запрос с учетными данными пользователя на сервер OAuth, который добавит новую запись в свою таблицу «oauth_users»? Если нет, что было бы лучшим и безопасным способом достижения этой функциональности?
Заранее спасибо!
Привет! В настоящее время они оба находятся в моей среде разработки, но в будущем могут быть развернуты отдельно. Я хотел бы прочитать ваши мысли по этому поводу?
Ответы 1
У нас такой подход работает.
На стороне базы данных Сервер аутентификации вы должны хранить только: идентификатор пользователя, URL-адрес перенаправления и настроенный авторизованный уровень обслуживания (области); предоставленные токены доступа; и другие требуемые данные разрешение (роли в вашем случае).
База данных Сервер входа в систему хранит: идентификатор пользователя, пароль и другие данные, относящиеся к аутентификация.
Служба пользовательских ресурсов (обычно RESTFul API) должен хранить: идентификатор пользователя и другие личные данные.
При новом запросе пользователя на защищенные данные ресурса (здесь требуется некоторая область действия) перенаправляет на сервер входа в систему, с этой успешной аутентификацией, перенаправляет на сервер аутентификации для предоставления разрешений с использованием этой области, генерирует токен доступа и перенаправляет на защищенный ресурс с токеном доступа, сервер ресурсов проверяет токен и область действия (некоторые реализации также делают еще один вызов Auth Server, чтобы проверить это с помощью JWT), чтобы наконец разрешить первоначальный запрос пользователя.
Вообще лично я использую принцип СУХОЙ с такой архитектурой.
Ваше здоровье!
Оба сервера находятся в разных местах или развернуты в одной среде?