2015-09-23 3 views
1

У меня есть общий вопрос о том, как обрабатываются области в протоколе OAuth2. Для простой аргументации можно начать с конкретного примера:Обработка области в протоколе OAuth2

Допустим, у меня есть сервер OAuth A, который я хочу использовать для защиты двух API RESTful R1 и R2. Эти две службы имеют специальные области, которые они используют, чтобы предоставить пользователю доступ к некоторым защищенным ресурсам. Так что давайте скажем, R1 нуждается в области S1 и R2 нуждается в области S2, чтобы получить доступ к ограниченным ресурсам.

Позволяет дополнительно предположить, что сервер OAuth A делает также использовать из областей email и profile, они необходимы, чтобы получить доступ к данным пользователя, сам OAuth сервер управляет.

Теперь вот что мне трудно понять. Насколько я вижу, сервер OAuth A обычно знает, как обрабатывать области, которые он сам использует (в данном случае email и profile). Но как насчет областей, необходимых для доступа к ограниченным функциям в двух API (R1 нужны S1 и R2S2)?

Должен ли я регистрировать эти области вручную с помощью сервера OAuth (чтобы он знал, что они существуют и могут предоставить их, если это необходимо)? Это снова означало бы, что мне нужно зарегистрировать все области всех API, которые я хочу защитить/использовать с помощью сервера OAuth.

Правильность этих допущений? Если у меня что-то не так, возможно, кто-то может мне помочь, объяснив, как обычно выполняется вся обработка области. Я попытался использовать google oauth2 и области видимости, но, похоже, нет хорошего объяснения того, как точно обрабатываются области в протоколе.

ответ

2

Поскольку это OAuth2 сервер авторизации A выдавать ОТВЕТСТВЕННОСТЬ токенов, и что маркеры доступа предоставляются с определенными областями, это звучит разумно иметь A знать о S1 и S2.

Это не совсем необходимо, A может обрабатывать область как «непрозрачные» строки и не заботиться, но регистрация областей с помощью A дает вам возможность проверить, что запрошенные области (и не являются случайными строками), а также как отображать более содержательное сообщение в приглашении, отображаемом пользователю во время потока авторизации («Разрешить« клиент OAuth2 »получить доступ к вашим данным R1, что означает« blablabla », а не« Предоставить доступ к S1 »).

+0

Чтобы обернуть его, представляется хорошей идеей реализовать функциональность в OAuth Server 'A', которая позволяет управлять областями (CRUD). Таким образом, сервер действительно должен знать все области, которые необходимы защищенным службам в конце концов? Спасибо за Ваш ответ! – evermean