Дизайн для проверки подлинности Facebook в приложении iOS, который также обращается к защищенной веб-службе

Цель: Разрешить пользователю аутентификацию с помощью Facebook в приложении iOS, для которого требуется доступ к защищенной веб-службе, которую я запускаю.

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

Детали:

  • Предположим, мы хотим предложить пользователю возможность входа в систему с помощью Facebook без создания отдельной учетной записи/учетных данных для нашей системы.
  • Поскольку мы поддерживаем собственный собственный механизм auth (имя пользователя и пароль), у нас есть собственные идентификаторы пользователей и выдается токен аутентификации, который используется для последующих взаимодействий после первоначальной проверки достоверности.

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

Здесь мои первоначальные мысли о том, как это было бы разработано, но хотят проверить правильность его.

  • Клиент выталкивает вход iOS в Facebook
  • Пользовательский интерфейс подписывается с учетными данными Facebook и получает токен доступа.
  • Приложение iOS передает токен доступа на наш сервер

  • Наш сервер разговаривает с API-интерфейсом FB, используя токен доступа, чтобы (a) проверить токен и (b) получить идентификатор пользователя FB для этого токена доступа.

    например. Наш сервер будет вызывать https://graph.facebook.com/me/?access_token=XYZ, который будет возвращать информацию профиля в объекте JSON

  • Предполагая, что он действителен, наш сервер извлекает идентификатор пользователя из объекта JSON и проверяет, имеет ли пользователь уже учетную запись. Если это так, мы выдаем наш собственный билет авторизации клиенту для использования на этом сеансе. Если у пользователя нет учетной записи, мы создаем новую с идентификатором пользователя Facebook, присваиваем свой собственный уникальный идентификатор пользователя и выдаем наш авторизационный билет.

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

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

ОТВЕТЫ

Ответ 1

Я только что имел дело с этим сам, и вот часть, которая укусила меня:

На вашем шаге 5... Пользователь может зарегистрировать учетную запись с вами совершенно отдельно от своего идентификатора в Facebook, верно? Затем в другой раз они входят в систему с Facebook.... И вы просто создали им вторую учетную запись и потеряли их первую.

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

Кроме того, ваш план звучит убедительно.

Обновление: Facebook добавил документ с изложением такого сценария ЗДЕСЬ

Ответ 2

Используйте https для передачи токена авторизации на ваш сервер, как указано Facebook

Обмен токенами доступа

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

Ответ 3

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

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

Одним из возможных способов использования этого может быть: для кого-то создать свой собственный сайт или мобильное приложение, получить токены доступа для своих пользователей и попытаться аутентифицировать их, используя ваш API. Если это удастся (у пользователя есть учетная запись facebook на вашем сайте), злонамеренный сайт сможет использовать ваш API, олицетворяющий пользователя.

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

Изменить: похоже, есть способ проверить токен доступа. См. Ответ @Daaniel на вопрос Получить идентификатор приложения из токена доступа пользователя (или проверить исходное приложение для токена).

Ответ 4

Ваше решение полностью работает.

Может быть, альтернатива: почему бы просто не получить электронную почту на клиенте из первоначального запроса социальной службы и отправить на ваш веб-сервис? Веб-служба может просто сохранить электронную почту, а может быть, и social_provider. Я понимаю, что ваш веб-сервис не сможет проверить, откуда пришел этот адрес электронной почты, но разве у вас нет высокоприоритетных отношений между вашим веб-сервисом и вашим клиентом? Если есть, кажется, что вы можете зависеть от электронной почты, исходящей из нужного места. Кто-то, пожалуйста, дайте мне знать, какую очевидную вещь мне не хватает, что делает почтовый подход глупым...

Ответ 5

Вопрос - Если вы собираетесь снова назначить свой уникальный идентификатор, зачем начинать с входа в FB? И будет ли снова использоваться тот же идентификатор, если человек снова войдет в FB?