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

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

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

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

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

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

Ответ 1

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

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

В случае с Twitterем (возможно, ваше дело тоже) оба выглядят нормально.

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

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

Ответ 2

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

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