Если я правильно понимаю, чтобы выполнять вызовы API из моего настольного приложения (давайте назовем его сейчас и на «клиенте», как в стандарте OAuth2), мне нужно получить access_token, который является идентификатором, который объединяет как идентификатор приложения, так ипользователь, данные которого я хочу получить, id («владелец ресурса»).
Следование клиентскому потоку в руководстве по аутентификации ( developers.facebook.com / docs / authentication / ) Iпонимаю, что мне нужно отправить запрос на h ** ps: //www.facebook.com/dialog/oauth? client_id = YOUR_APP_ID & redirect_uri = http://example.com&response_type=token. В результате страница будет перенаправлена на пример h ** p: //.ком / # access_token = XXX.Если клиент является чисто настольным приложением, тогда redirect_uri может быть h ** p: //www.facebook.com/connect/login_success.html.Поскольку клиент владеет веб-элементом управления, access_token может быть легко извлечен из перенаправленного адреса.
Поток на стороне клиента состоит из 3 шагов OAuth:
- Аутентификация пользователя, если владелец ресурса не вошел в Facebook, отобразится диалоговое окно с запросом учетных данных Facebook.Если владелец ресурса вошел в систему, сеанс будет аутентифицирован с использованием файла cookie на серверах Facebook.Безопасность - ПРОВЕРИТЬ V!
- Авторизация приложения, если владелец ресурса еще не дал разрешения для приложения, диалоговое окно разрешений попросит владельца ресурса предоставить разрешения приложению, если владелец ресурса ранее предоставил все права доступа.необходимое разрешение, диалог разрешений не будет показан.Безопасность - ПРОВЕРИТЬ V!
- Аутентификация приложения - вот где оно становится липким.В руководстве говорится: «Проверка подлинности приложения выполняется путем проверки того, что redirect_uri находится в том же домене, что и URL-адрес сайта, настроенный в приложении для разработчиков».Безопасность - по моему мнению - FAIL !
Почему я считаю, что последний шаг - это сбой безопасности?Прежде всего, и идентификатор приложения, и redirect_uri являются общедоступной информацией, которую может получить каждый.Во-вторых, redirect_uri может быть h ** p: //www.facebook.com/connect/login_success.html.
Давайте посмотрим на следующий сценарий.Настольное приложение EVE показывает пользователю веб-элемент управления, где пользователь входит в Facebook и предоставляет EVE некоторые основные разрешения.У владельца ресурса нет причин подозревать что-либо.Затем EVE скрывает веб-элемент управления и пытается загрузить на него h ** ps: //www.facebook.com/dialog/oauth? Client_id = OTHER_APP_ID & redirect_uri = http://www.facebook.com/connect/login_success.html&response_type=token. Приложение может попробоватьи загрузите этот URL с самыми популярными идентификаторами приложений приложений Facebook.Приложение получит сообщение об успехе, если пользователь ранее авторизовал OTHER_APP, так как диалог входа в систему и диалог разрешений не будут отображаться.Это даст EVE access_token для доступа ко всем ресурсам владельца ресурса, которые владелец ресурса предоставил OTHER_APP, а не EVE.
Итак, это дыра в безопасности?Я что-то пропустил в следующем?
(ОБНОВЛЕНИЕ)
Очевидно, что в случае настольного приложения проблемы безопасности не имеют значения, поскольку в приложении уже есть имя пользователя, сеанс facebook и даже имя пользователяи пароль, он может делать что угодно с учетной записью пользователя.
(ОБНОВЛЕНИЕ) Для приложений JavaScript, которые работают в веб-браузере, redirect_uri действительно работает!(См. Ответ и комментарии hnrt).
ТЕКУЩИЙ ВОПРОС: Единственная оставшаяся загадка - как работает аутентификация клиента в приложениях для iPhone и Android?Является ли безопасность в целом похожа на ту, что при использовании настольного приложения?Есть ли какая-то разница в джейлбрейкнутых iPhone или рутированных Android?
Ура!