Переносимость маркеров доступа

В этом руководстве описаны распространенные сценарии, связанные с переносимостью. Это поможет вам подобрать оптимальную конфигурацию при разработке приложения.

Использование маркеров с приложениями разных типов

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

Конфигурация	Преимущества	Недостатки	Примечания по безопасности
Вход и запросы API осуществляются через веб-клиент (краткосрочный маркер).	Простая реализация.	Отсутствует возможность размещать публикации в режиме офлайн. Отсутствует возможность долгосрочного доступа. Частая авторизация.
Вход и запросы API осуществляются через нативный мобильный клиент или веб-клиент (долгосрочный маркер).	Не такая частая авторизация.	Отсутствует возможность размещать публикации в режиме офлайн.
Вход и запросы API осуществляются через веб-клиент (долгосрочный маркер после обмена кодом).	Дополнительная безопасность в некоторых ситуациях.	Сложная реализация. Отсутствует возможность размещать публикации в режиме офлайн.	Подходит только для определенных ситуаций.
Вход выполняется через нативный мобильный клиент или веб-клиент. Запросы API выполняются на сервере (с долгосрочным маркером).	Возможность размещать публикации в режиме офлайн. Дополнительные функции безопасности благодаря серверным вызовам.	Клиент должен вызывать сервер для доверенной передачи всех вызовов.	Для вызовов используется параметр `appsecret_proof`.
Вход выполняется через нативный мобильный клиент или веб-клиент. Запросы API выполняются на сервере или в клиенте.	Возможность размещать публикации в режиме офлайн. Размещение публикаций из клиента по инициативе пользователя.	Сложная реализация.	Для вызовов от сервера используется параметр `appsecret_proof`.

Вход и запросы API через нативный или веб-клиент

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

Нативный или веб-клиент осуществляет аутентификацию и использует возвращенный краткосрочный или долгосрочный маркер для вызовов.
Веб-клиент осуществляет аутентификацию и обменивает краткосрочный маркер на долгосрочный через сервер. Долгосрочный маркер отправляется обратно в веб-клиент, который затем использует его для вызовов API.
Веб-клиент осуществляет аутентификацию и обменивает краткосрочный маркер на долгосрочный через сервер. Сервер отправляет клиенту код. Клиент обменивает код на долгосрочный маркер и использует его для вызовов API. Такая конфигурация применяется редко.

Процесс с использованием нативного или веб-клиента

Процесс с использованием веб-клиента и долгосрочного маркера

Процесс с использованием веб-клиента и обмена кодом

Вход из клиента и серверные вызовы API

В этой распространенной конфигурации аутентификация происходит на стороне клиента, а вызовы API совершаются сервером от имени клиента. Для дополнительной безопасности при совершении вызовов сервер может использовать параметр appsecret_proof.

Вход из клиента и клиентские или серверные вызовы API

Эта конфигурация представляет собой сочетание двух описанных выше подходов.

Настройка маркеров доступа с помощью SDK

Указать, какие маркеры доступа должны использоваться при вызове API в наших SDK, можно несколькими способами.

В методе setCurrentAccessToken Facebook SDK для Android есть параметр accessToken.
В методе setCurrentAccessToken Facebook SDK для iOS есть параметр token.
В методе FB.api() Facebook SDK для JavaScript есть параметр access_token.