Разработка аутентификации Facebook в приложении для iOS, которое также обращается к защищенному веб-сервису

Question

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

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

подробности:

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Совместное использование токенов доступа

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

Answer 3

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

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

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

Это немного, но я думаю, что это может сработать.

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

Answer 4

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

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