Рекомендации по работе с токенами и областями доступа для реализации OAuth2?

Question

Предположим, у нас есть реализация OAuth2, которая поддерживает область «чтение» и «запись».

Я получаю токен доступа "f482c829" с областью чтения. Если я потом передумал и теперь хочу разрешения на чтение + запись и авторизируюсь снова с областями «чтение» и «запись», вы:

• Обновить области для существующего токена доступа и вернуть тот же токен "f482c829"?
• Если используется тот же токен, требуется ли повторно использовать токен доступа при использовании response_type = code перед обновлением областей? (Думаю да)
• Обновить области для существующего токена доступа и вернуть обновленный токен "zf382nL"?
• Создать совершенно новый токен, оставив "f482c829" и его области действия нетронутыми?

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

Спецификация OAuth2 (по состоянию на черновик-12), к сожалению, не решает ничего из этого.

Answer 1

В случае Facebook ресурсный сервер в основном совпадает с сервером авторизации.Таким образом, они используют способ «использовать существующий токен».И это позволяет пользователям отключать каждую область на сайте facebook.com.Что касается токена обновления, вам не нужно устанавливать новый токен обновления.(Конечно, вы можете сделать это, хотя.) Существующий токен обновления также будет связан со всеми областями действия.

В случае Google (возможно, и Yahoo!) сервер ресурсов полностью отличается от авторизации.сервер.Многие ресурсные серверы (Docs, Buzz и т. Д.) Принимают токены доступа, установленные одним сервером авторизации.В этом случае способ «установить новый токен» кажется лучше.

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

Поскольку разработчик должен предварительно зарегистрировать redirect_uri, использование одинаковых учетных данных клиента как на веб-сайте, так и на мобильном устройстве кажется сложным.Поэтому я рекомендую попросить разработчиков использовать разные учетные данные клиента в этом случае.

Answer 2

Допустим, одному клиенту (мобильному) приложения требуется доступ только для чтения, а другому клиенту (веб-сайту) также необходимо писать. Это потребовало бы, чтобы клиент мог определять объем запроса токена, и, следовательно, поставщик мог хранить несколько токенов с разными областями действия.

Однако вам решать, хотите ли вы расширить область действия существующего токена. Это означает, что вы можете сохранить одну область для приложения. Это также может упростить отзыв доступа пользователя к приложению.