Может кто-нибудь объяснить, почему токены запроса должны быть обменены на токены доступа после утверждения пользователем? Почему бы не притвориться, что токен запроса является токеном доступа, как только пользователь одобрил доступ?запрос и токены доступа в oauth
Краткий ответ: аутентификация приложения.
Обратитесь к YouTube's OAuth Process Flow Diagram
OAuth представляет собой 3-протокол ножек. В этом конкретном случае YouTube должен аутентифицировать два разных объекта: a) пользователь и b) приложение, которому требуется accss.
Теперь, после того как пользователь предоставляет доступ (шаг 10 на диаграмме), YouTube знает, что «Пользователь x хочет предоставить Y доступ к Y для YouTube». Но он еще не подтвердил приложение Y. Приложение-изгои может выполнить все шаги до шага 10, притворяясь действительным известным приложением, - и такое действие должно быть предотвращено.
В последних трех шагах приложение проверяет себя на YouTube, подписывая запрос. Как только это будет сделано, YouTube может безопасно предоставить токен доступа к приложению.
Система oauth проверяет токен запроса и проверяет, разрешен ли доступ для этого пользователя. Затем он выдает токен доступа (действительный на определенный период) и подписывает его цифрой.
Подпись важна, так как это показывает, что система согласна с тем, что запрашивателю разрешен доступ, который он запросил.
Посмотрите на: http://hueniverse.com/oauth/ для простого проглатывания руководства о том, как все это работает.
Это не отвечает на мой вопрос. Я пытаюсь понять, почему протокол настолько запутан с таким количеством токенов. Я вижу, что все работает с одним токеном запроса. – davidk01 2010-12-02 12:27:35