it-roy-ru.com

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

Зачем вам нужен и "код", и "токен" в процессе аутентификации 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, если впервые получаете токен в диалоговом окне.

58
jkeesh

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

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

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

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

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

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

38
Kris Subramanian

Беззастенчиво заимствовано у Salesforce Documentation :

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

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

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

27
Drew

Из OAuth 2.0 Spec :

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

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

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

21
Scott T.

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

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

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

На шаге 2: клиент (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)

7
arganzheng

Перепутывание произошло из-за того, что пользователь от своего имени, а не клиентское приложение, проходит проверку подлинности на сервере авторизации (т.е. 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. Аутентифицировать клиентов во время прямого запроса между клиентом и сервером авторизации намного проще, чем в контексте запроса косвенной авторизации. Последнее потребует цифровых подписей.

5
Eitan Rimon

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

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

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

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

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

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

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

3
dchoi-vindicogroup

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

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

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

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

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

2
Michael R

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

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

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

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

enter image description here

2
Amit Kumar Gupta

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

1
Justin Ehrlich