Я работаю над сервером OAuth 2.0 для поддержки нескольких клиентов и ролей.Как обрабатывать несколько клиентов и роли?
Предположим, у меня есть сервер API, для которого требуется токен доступа с сервера OAuth.
Эти рабочие процессы я придумал. У меня три функции для этого простого рабочего процесса: OAuth, Клиент и Сервер API.
- Пользователей на каждом клиенте есть адрес электронной почты и пароль (эти учетные данные хранятся на OAuth-сервере)
- пользователей подписываются в их адрес электронной почты и пароль на свои клиентах, то клиенты отправляют учетные данные на сервер OAuth для аутентификации ,
- Сервер OAuth проверяет учетные данные и выдаёт токен доступа.
- Когда пользователь запрашивает запрос на сервер API, сервер API ведет переговоры с сервером OAuth, чтобы узнать, имеет ли пользователь доступ к ресурсу. Если это так, выполните запрошенный запрос и верните что-то.
Это несколько необычный рабочий процесс, на мой взгляд. Причина, по которой я хочу сделать это, заключается в том, что мы фактически храним учетные данные пользователя на нашем сервере OAuth. У меня также есть несколько ролей (групп) для каждого клиента.
Это обходное решение OKAY или есть лучший способ для одного клиента OAuth + и нескольких ролей?
Спасибо, Hans Z. Проблема, которую я вижу, заключается в том, что клиентское приложение должно знать или управлять областями на их конце. Например, пользователь admin «[email protected]» пытается войти в систему, какую область я должен запросить? Чтобы знать, что запрашивать, клиентские приложения должны знать о группах пользователей (или ролях), но я действительно не хочу этого делать. Я предполагаю, что могу использовать учетную запись пользователя для выдачи токена доступа, а затем проверить область, когда пользователь действительно запрашивает что-то. – Moon
Клиент не должен знать области видимости, особенно не в предоставлении полномочий учетных данных владельца ресурса. В любом случае вам не нужно явно запрашивать области действия, вы также можете связать все области, которые вы хотите, с токеном доступа на сервере авторизации. Тогда клиент может даже не знать о облаках: он просто получает токен доступа и использует его для успеха или неудачи в соответствии с базовыми разрешениями/ролями, обычно это производный набор разрешений/ролей владельцев ресурсов. –
Спасибо, Hans Z. Я думаю, что это лучший способ справиться с этим до сих пор. – Moon