Почему у OAuth есть токен запроса и токен доступа?

Question

В протоколе OAuth потребитель службы запрашивает у пользователя авторизацию токена запроса в домене поставщика услуг, а затем обменивает токен запроса на токен доступа от поставщика услуг.

Мне интересно, почему в протоколе OAuth предусмотрено два токена.

Почему бы просто не использовать один единственный токен в этом процессе? То есть пользователь авторизует токен , а потребитель службы будет получать информацию от провайдера с помощью токена .

Answer 1

Из соображений удобства использования и безопасности.

Из Руководство для начинающих по OAuth :

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

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

===

Обратите внимание, что этот вопрос является обманом

Почему мы должны "изменить временные учетные данные для учетных данных токена"в OAuth?

Если объяснение из Руководства для начинающих неясно, тогда читайте @ npdoty's take on .

Answer 2

С Официальное руководство OAuth 1.0

Протокол OAuth включает веб-сайты или приложения (потребители) для доступа Защищенные ресурсы от веб-службы (Поставщик услуг) через API, без требуя от пользователей раскрывать свои Учетные данные поставщика услуг Потребители. В целом, OAuth создает свободно реализуемую и общая методология для API аутентификации.

Пример использования служба печати printer.example.com (Потребитель), чтобы получить доступ к частным фотографии хранятся на photos.example.net (Поставщик услуг) без требуя от пользователей предоставить свои Учетные данные photos.example.net для printer.example.com.

OAuth не требует конкретного пользователя интерфейс или шаблон взаимодействия, ни это определяет, как поставщики услуг аутентифицировать пользователей, делая протокол идеально подходит для случаев где учетные данные аутентификации недоступны для потребителя, такие как с OpenID.

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

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