Почему мы должны «изменить временные учетные данные для учетных данных токена» в OAuth? - PullRequest
6 голосов
/ 04 марта 2010

Может ли сервер просто "обновить" временные учетные данные до учетных данных токена и сохранить тот же ключ и секрет?

Затем клиент может начать выполнять аутентифицированные вызовы сразу после получения обратного вызова от сервера, сообщающего, что временные учетные данные были «обновлены».

Конечно, если временные учетные данные не подлежат обновлению (т. Е. Клиент не ожидает обратного вызова), аутентифицированный вызов не выполняется.

Итак, вопрос в том, зачем после обратного вызова делать дополнительный вызов на сервер, чтобы «обменять» временные учетные данные на учетные данные токена?

1 Ответ

10 голосов
/ 08 марта 2010

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

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

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

Таким образом, насколько я понимаю, ограничив токен доступа каналом, непосредственно соединяющим потребителя (ваш сервис) и провайдера (сервис, к которому вы получаете доступ), вы можете получить безопасный токен доступа (то есть один злоумышленник не имеет), даже если компьютер пользователя или сетевое подключение пользователя к вашему сервису скомпрометировано. Если бы маркер запроса был просто обновлен, то любой, кто прослушивал сетевое соединение пользователя, мог легко получить токен запроса / доступа, который мы предпочли бы хранить в тайне, поскольку его можно использовать (с вашим токеном потребителя, конечно), возможно очень долго, чтобы получить доступ к данным пользователя. Соединение между серверами часто более безопасно.

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

...