Для гибридного сценария SSO с использованием iOS SDK для Facebook, какой лучший способ генерировать пароль/ключ для наших собственных пользовательских записей?

Итак, я намерен иметь логин в своем приложении iOS, который позволяет либо выполнить стандартную регистрацию по электронной почте /pwd, либо войти в систему с помощью Facebook. Мы также создаем службы отдыха для получения информации о приложении для данного пользователя, например. HTTPS://URL/getPosts/[идентификатор пользователя] userPwd = Foo

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

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

Я мог бы вставить запись в мою собственную таблицу пользователей, когда они fbDidLogin с Facebook, используя идентификатор Facebook как уникальный идентификатор, и токен доступа fb в качестве псевдо-пароля/ключа для моей собственной записи пользователя. Я должен был бы проверить токен доступа с Facebook, чтобы убедиться, что он действителен, прежде чем сохранять его в качестве пароля для пользователя (пользователь никогда не увидит этот пароль, он просто будет передан клиентским приложением во время вызовов api). Таким образом, когда пользователь делает вызов нашему собственному отдыху api через приложение iPhone, мы можем аутентифицировать и разрешать использование этого ключа secret/pwd/.

Альтернатива, которая позволила бы решить весь этот вопрос, - это просто обработать логику авторизации в клиентском приложении и проверить, существует ли действительный сеанс fb перед вызовом нашей собственной Apis, которую я защищаю только одним общесистемным секрет, но это не кажется столь же безопасным, поскольку получение того, что один секрет дает разрешение на данные для всех пользователей. Я бы предпочел авторизоваться на индивидуальном уровне пользователя. Это правильный выбор? Я параноик о безопасности iOS?

Ток доступа fb истекает, поэтому может показаться недолгим, однако, если я разрешаю офлайн-доступ, токен не истечет, но создает более страшное окно. Альтернативой токен доступа является хэш-идентификатор fb с секретным ключом приложения на iOS-клиенте и использование его в качестве пароля пользователя Facebook в нашем db. Тем не менее, это еще один секретный ключ, который, возможно, можно было бы скомпилировать из клиентского приложения iOS?

Ответ 1

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

Этот пост помог мне разоблачить его больше. Если я не ошибаюсь, поток будет выглядеть следующим образом:

  • Пользователь аутентифицируется в приложении iOS
  • Приложение iOS принимает токен аутентификации, отправляет его в приложение rails
  • Приложение Rails принимает токен аутентификации и отправляет его на graph.facebook.com/?auth_token=XXX, чтобы вернуть пользователя, если аутентификация прошла успешно.
  • Приложение Rails принимает информацию о пользователе и сопоставляет/создает пользователя в собственной таблице базы данных. Отправляет какой-то ключ аутентификации в приложение iOS.
  • Приложение iOS сохраняет ключ аутентификации, поэтому он может использовать его для связи с приложением rails.

Сообщите мне, если я что-то упустил.

Ответ 2

Вы просмотрели документы iOS для Single Sign On (SSO)? https://developers.facebook.com/docs/guides/mobile/#ios

Вы можете делиться идентификатором приложения на мобильном, холсте и веб-сайте, и для каждой среды работает одна и та же пользовательская аутентификация.

Отъезд: https://developers.facebook.com/docs/authentication/

Платформа Facebook предлагает несколько способов использования вышеуказанных потоков OAuth в разных типах приложений, включая веб-сайты, приложения на Facebook.com, мобильные и настольные приложения.

Ответ 3

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