Facebook OAuth 2.0 "код" и "токен"

Question

Зачем вам нужны и "код", и "токен" в потоке аутентификации OAuth2 на Facebook, как описано здесь: https://developers.facebook.com/docs/authentication/?

Если вы посмотрите ссылку на диалог OAuth (https://developers.facebook.com/docs/reference/dialogs/oauth/), похоже, что вы когда-либо использовали токен для получения информации о пользователе, и если вы указали параметр response_type как token или code,token, то вы получите токен в первый раз.

Зачем вам нужен «код», а затем использовать код для получения «токена», а не напрямую получать токен?

Я полагаю, что я неправильно понимаю кое-что базовое о том, какOAuth работает, но, похоже, вы полностью избегаете запроса на https://graph.facebook.com/oauth/access_token, если первый раз получаете токен с диалоговым окном.

Answer 1

Давайте рассмотрим простой пример, чтобы отличить код аутентификации от токена доступа.

Вы, как пользователь, хотите попробовать новое приложение Facebook под названием Highjack.Таким образом, вы нажимаете на приложение и приложение Highjack.просит вас войти в свою учетную запись Facebook.Когда вы закончите, Facebook генерирует код аутентификации для вас.

Этот код затем передается на сервер Highjack, который использует свой собственный идентификатор клиента FB, секрет FB и ваш код аутентификации для получения токена доступа.

В приведенном выше примере код аутентификации подтверждает, что вы являетесь действительным пользователем FB.Но на втором этапе говорится: «Вы, как пользователь FB, предоставляете доступ к приложению Highjack для определенных ресурсов».

Если приложению Highjack требуется неявное предоставление (т. Е. Токен прямого доступа), то токен доступа будет виден вам также, поскольку он обменивается с браузером.Это означает, что теперь вы можете вызывать все API Facebook от имени Highjack, используя токен доступа.(Вы можете использовать токен доступа только для получения вашей личной информации, но Facebook не может узнать, кто вызывает их API.)

Так как у нас есть 2 участника (вы и Highjack), проходящие аутентификацию с Facebook, у нас есть это 2механизм складывания.

Answer 2

Заимствовано беззастенчиво от Документация Salesforce :

Код авторизации

Код авторизации - это кратковременный токен , представляющий разрешение доступа пользователя, созданное сервером авторизации и переданное клиентскому приложению через браузер. Клиентское приложение отправляет код авторизации на сервер авторизации для получения токена доступа и, необязательно, токена обновления.

Токен доступа Маркер доступа используется клиентом для выполнения аутентифицированных запросов от имени конечного пользователя. У него более длительный срок службы , чем у кода авторизации, обычно порядка минут или часов. Когда срок действия маркера доступа истекает, попытки использовать его не удаются, и новый токен доступа должен быть получен через токен обновления.

Answer 3

Из спецификации OAuth 2.0 :

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

Итак, в основном - основная причина заключается в ограничении числа действующих лиц, получающих токен доступа.

Ответ «токен» предназначен в первую очередь для клиентов, которые живут в браузере (например, клиент JavaScript).

Answer 4

Если вы посмотрите на поток кода авторизации типа OAuth , да, есть два актуария:

1. <user_session_id, client_id> => authorization_code
2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token

В шаге 1: пользователь сообщает серверу OAuth, что «IЯ хочу авторизовать этот клиент (client_id) для доступа к моему ресурсу. Вот моя аутентификация (user_session_id или что еще) "

На шаге 2: client (client_id) сообщает серверу OAuth, что" у меня есть пользовательавторизация (код авторизации), пожалуйста, дайте мне токен доступа для последующего доступа. И это моя аутентификация (client_id & client_secret) "

Видите ли, если мы пропустим шаг 2, тогда не будет никакой гарантии для аутентификации клиента,Любой клиент может вызвать step1 с другим client_id и получить токен доступа для этого client_id вместо своего собственного.Вот почему нам нужен шаг 2.

Если вы действительно хотите объединить step1 и step2, вы можете сделать что-то вроде этого:

<client_id, redirect_uri, client_secret> => access_token, refresh_token

Мы используем этот подход в нашей платформе Open Api, и мы не нашли никакой защитыпроблема еще не решена.

Кстати, действительно существует Неявный тип предоставления , то есть:

<client_id, redirect_uri> => access_token, refresh_token

Обычно применяется только к клиентским приложениям, у которых нет серверабэкенд.В этом случае сервер OAuth должен убедиться, что URI перенаправления принадлежит этому клиенту (например, то же самое с регистром redirect_uri)

Answer 5

Перепутывание произошло из-за того, что пользователь от своего имени, а не клиентское приложение, проходит проверку подлинности на сервере авторизации (т. Е. Facebook). Намного проще защитить клиентское приложение (с помощью https), затем пользовательский агент (браузер).

Вот оригинальная формулировка от IETF-oauth (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4):

3,4. Код авторизации

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

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

2. Гораздо проще проверять подлинность клиентов во время прямого запрос между клиентом и сервером авторизации, чем в контекст запроса косвенной авторизации. Последний бы требовать цифровые подписи.

Answer 6

Ответ) Вам нужен / нужен код и токен для дополнительной безопасности.

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

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

Для получения дополнительной информации посмотрите это фантастическое видео:

OAuth 2.0 и OpenID Connect (простым языком) https://youtu.be/996OiexHze0?t=26m30s (начало 26 минут)

Answer 7

По сути, как расширение ответа Ликса , маршрут кода доступа позволяет Владельцу ресурса (то есть пользователю Facebook) отозвать авторизацию для своего пользовательского агента (то есть своего браузера), например, выйдя из системы,без отзыва авторизации для автономного клиента (т.е. вашего приложения).Если это не важно, тогда нет необходимости использовать маршрут кода доступа.

Кроме того, предоставляется код доступа, чтобы гарантировать, что токен, предоставленный серверу, действительно зарегистрирован владельцем ресурса (т. Е.Пользователь Facebook), а не пользовательский агент (или Человек-посредник).

Это похоже на вопрос выбора неявного потока разрешения кода авторизации против. На самом деле, вот что выглядит как противоположная точка зрения?! .

Кроме того, как Дрю упомянул ,

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

другой элемент является токеном обновления, но я не вижу, что это также объясняетсяхорошо в FB Docs.Если я прав, неявное предоставление (прямой токен) должно быть действительно недолгим, но это должно быть принудительно выполнено, и FB.js, кажется, скрывает многое из этого (это я не изучал так глубоко).

Если я не ошибаюсь, code%20token - это оптимизация, позволяющая агенту пользователя иметь токен и позволяющая серверу инициировать процесс обмена токенами в одном запросе (как что-либо через сетевой ввод-вывод).считается дорогим, особенно для агента пользователя).

Answer 8

Теоретически

• Токены доступа не может сказать нам, если пользователь прошел аутентификацию, но аутентификационный код делает.
• Код доступа не должен использоваться для получения доступа к API, но токен доступа должен быть.

Если у вас есть одностраничное приложение или мобильное приложение без или с минимальным бэкэндом, ваше приложение может захотеть получить доступ к данным FB пользователя непосредственно во внешнем интерфейсе. Следовательно токен доступа предоставляется.

В другом случае вы можете захотеть, чтобы пользователь зарегистрировался / вошел в ваше приложение с помощью какого-либо внешнего поставщика услуг аутентификации, такого как Facebook, Google и т. Д. В этом случае ваш веб-интерфейс отправит код авторизации на сервер, который можно использовать получить токен доступа из Facebook на стороне сервера. Теперь ваш сервер получает доступ к данным FB пользователя с сервера.

Answer 9

Это потому, что токен доступа предоставляется клиенту AUTHENTICATED (стороннее приложение) с использованием общего секрета, который известен только FB и клиенту.Единственный способ, которым пользователь мог напрямую запросить токен доступа, - это узнать общий секрет, который сделает его общедоступным и может привести к атаке «человек посередине».Кроме того, в то время как FB может гарантировать безопасное соединение с пользователем, FB не может гарантировать безопасную передачу токена клиенту.Однако FB (и OAuth2) требует безопасного соединения между клиентом и FB.Маркер доступа привязан к общедоступному идентификатору клиента (обычно хэшированному), что означает, что только исходное клиентское приложение может использовать его для запроса токена, поскольку секретный ключ отправляется вместе с кодом авторизации для получения токена доступа.

Answer 10

Вы получаете токен, когда пользователь входит в систему. Но вы можете изменить токен, когда выполняете другие действия. Например, публикация в качестве вашего приложения / страницы или публикация в качестве пользователя с offline_access.