Итак, я намерен иметь логин в своем приложении 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?