2015-01-12 3 views
0

Я работаю над сервером OAuth 2.0 для поддержки нескольких клиентов и ролей.Как обрабатывать несколько клиентов и роли?

Предположим, у меня есть сервер API, для которого требуется токен доступа с сервера OAuth.

Эти рабочие процессы я придумал. У меня три функции для этого простого рабочего процесса: OAuth, Клиент и Сервер API.

  1. Пользователей на каждом клиенте есть адрес электронной почты и пароль (эти учетные данные хранятся на OAuth-сервере)
  2. пользователей подписываются в их адрес электронной почты и пароль на свои клиентах, то клиенты отправляют учетные данные на сервер OAuth для аутентификации ,
  3. Сервер OAuth проверяет учетные данные и выдаёт токен доступа.
  4. Когда пользователь запрашивает запрос на сервер API, сервер API ведет переговоры с сервером OAuth, чтобы узнать, имеет ли пользователь доступ к ресурсу. Если это так, выполните запрошенный запрос и верните что-то.

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

Это обходное решение OKAY или есть лучший способ для одного клиента OAuth + и нескольких ролей?

ответ

1

Что вы описываете, это эквивалент разрешения учетных данных пароля владельца ресурса в OAuth 2.0, см.: https://tools.ietf.org/html/rfc6749#section-1.3.3. Вы должны иметь возможность сделать это с помощью сервера авторизации OAuth 2.0, который поддерживает этот грант. Таким образом, это не является чем-то необычным или проприетарным, но требует большого доверия к клиенту, потому что он «видит» пароль.

Вы можете моделировать несколько ролей и групп, представляя их как разные «области», связанные с токенами доступа и, таким образом, клиентами.

+0

Спасибо, Hans Z. Проблема, которую я вижу, заключается в том, что клиентское приложение должно знать или управлять областями на их конце. Например, пользователь admin «[email protected]» пытается войти в систему, какую область я должен запросить? Чтобы знать, что запрашивать, клиентские приложения должны знать о группах пользователей (или ролях), но я действительно не хочу этого делать. Я предполагаю, что могу использовать учетную запись пользователя для выдачи токена доступа, а затем проверить область, когда пользователь действительно запрашивает что-то. – Moon

+0

Клиент не должен знать области видимости, особенно не в предоставлении полномочий учетных данных владельца ресурса. В любом случае вам не нужно явно запрашивать области действия, вы также можете связать все области, которые вы хотите, с токеном доступа на сервере авторизации. Тогда клиент может даже не знать о облаках: он просто получает токен доступа и использует его для успеха или неудачи в соответствии с базовыми разрешениями/ролями, обычно это производный набор разрешений/ролей владельцев ресурсов. –

+0

Спасибо, Hans Z. Я думаю, что это лучший способ справиться с этим до сих пор. – Moon