Почему мы должны «менять временные учетные данные для учетных данных токена» в OAuth?
Может ли сервер просто «обновить» временные учетные данные до учетных данных токена и сохранить тот же ключ и секрет?
Затем клиент может запустить выполнение аутентифицированных звонков сразу после получения обратного вызова с сервера о том, что временные учетные данные были «обновлены».
Разумеется, если временные учетные данные не подлежат обновлению (т. Е. Клиент не ожидает обратного вызова), аутентифицированный вызов не выполняется.
Поэтому возникает вопрос, зачем делать дополнительный вызов на сервер после обратного вызова для «exchange» временные учетные данные для токена?
1 ответ
Вы могли реализовать OAuth таким образом, но, насколько я понимаю, отделение токенов запроса от токенов доступа обеспечивает дополнительный уровень безопасность.
Из Руководства для начинающих :
OAuth включает два типа токенов: токен запроса и токен доступа. Каждый токен играет особую роль в рабочем процессе делегирования OAuth . Хотя в основном является артефактом развития спецификации OAuth , конструкция с двумя токенами обеспечивает удобство использования и функции безопасности, которые сделали его стоит оставаться в спецификации . OAuth работает по двум каналам: передний канал, который используется для взаимодействия с пользователем и запроса авторизации, и задний канал, используемый Потребителем. для прямого взаимодействия с поставщиком услуг. Ограничивая токен доступа на обратном канале, сам токен остается скрытым от пользователя.Это позволяет токену доступа иметь особое значение и иметь больший размер, чем токен запроса внешнего канала, который предоставляется пользователю при запросе авторизация, и в некоторых случаях требуется вводить вручную (мобильное устройство или телеприставка).
Итак, насколько я понимаю, ограничивая токен доступа каналом непосредственно между потребителем (вашей службой) и поставщиком (службой, к которой вы получаете доступ), вы можете получить безопасный токен доступа (то есть , которого нет у злоумышленника), даже если компьютер пользователя или его сетевое подключение к вашей службе скомпрометировано. Если бы токен запроса был просто обновлен, то любой, кто обнюхивал сетевое соединение пользователя, мог легко получить токен запроса / доступа, который мы предпочли бы сохранить в секрете, поскольку его можно использовать (конечно, с вашим токеном потребителя), потенциально очень долго, чтобы получить доступ к данным пользователя. Межсерверное соединение часто бывает более безопасным.
Кроме того, как указано выше, это позволяет вам иметь гораздо более длинный ключ в тех случаях, когда токен запроса действительно должен быть напечатан пользователем (и поэтому, вероятно, он очень короткий).