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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Из OAuth 2.0 Spec:

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

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

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

Ответ 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, что "я хочу авторизовать эту клиентскую среду (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)

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Кроме того, как Дрю отметил,

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

В OAuth 2.0 с Facebook общая концепция проста:

Шаг 1. Получить "Код авторизации" с помощью запроса GET

request URI: https://www.facebook.com/dialog/oauth
Params:
    response_type=code
    client_id={add your "App id" got by registering app}
    redirect_uri={add redirect uri defined at the registration of app}
    scope={add the scope needed in your app}
Headers: None

Шаг 2. Получите "токен доступа", отправив код авторизации в виде запроса POST

    URI: https://graph.facebook.com/oauth/access_token
    Params:
        grant_type=authorization_code
        client_id=<add your "App id" got by registering app>
        redirect_uri=<add redirect uri defined at the registration of app>
        code=<obtained authorization code from previous step>
    Headers:
        Authorization:Basic encode <App Id:App Secret> with base64 
        Content-Type:application/json

Шаг 3. Используйте токен доступа, полученный из вышеприведенного шага, и получите ресурсы пользователя.

Ответ 11

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