В протоколе OAuth потребитель службы попросит пользователя разрешить токен запроса в домене поставщика услуг, а затем обменяет токен запроса на токен доступа от поставщика услуг.
Мне интересно, почему OAuth рассчитан на наличие двух токенов в протоколе.
Почему бы просто не использовать один единственный токен в этом процессе? То есть пользователь будет разрешать токен, а потребитель службы будет получать информацию от поставщика с помощью токена.
Для удобства использования и безопасности.
Из Руководство для начинающих по OAuth:
https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5
... Хотя в основном артефакт о том, как спецификация OAuth эволюционировала, дизайн двух токенов предлагает некоторые удобства использования и безопасности, что сделало его целесообразным оставаться в спецификации. OAuth работает по двум каналам: фронтальный канал, который используется для вовлечения пользователя и авторизации запроса, и обратный канал, используемый потребителем для непосредственного взаимодействия с поставщиком услуг. Ограничив токен доступа на обратный канал, сам токен остается скрытым от пользователя. Это позволяет токену доступа иметь специальные значения и иметь больший размер, чем токен запроса на переднем канале, который предоставляется пользователю при запросе авторизации, а в некоторых случаях необходимо вводить вручную (мобильное устройство или телеприставка).
===
Обратите внимание, что этот вопрос является обманом
Почему мы должны "изменять временные учетные данные для учетных данных токена" ? в OAuth?
Если объяснение из руководства для начинающих не ясно, перейдите к @npdoty.
От Официальное руководство 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 маркер запроса, и они получают токен доступа. Это делает так, что служба никогда не видит/использует имя пользователя и пароль.