Дизайн для аутентификации Facebook в приложении iOS, которое также обращается к защищенной веб-службе
цель: Разрешить пользователю аутентификацию с помощью Facebook в приложение iOS, которое требует доступа к защищенной веб-службе, которую я запускаю.
предположения: Существует собственная система аутентификации (и регистрации) для тех пользователей, которые предпочитают не использовать Facebook для входа.
детали:
- предположим, что мы хотим предложить пользователю возможность войти в систему с Facebook без создание отдельной учетной записи / учетных данных для нашей системы.
- поскольку мы поддерживаем наш собственный собственный механизм аутентификации (имя пользователя и пароль), у нас есть собственные идентификаторы пользователей и выдаем маркер аутентификации, который используется для последующих взаимодействий после первоначальной проверки учетных данных.
Я удивлен, что Facebook не имеет лучших практик для этого в своей документации разработчика. Вся существующая документация либо предполагает, что вы строите FB auth в a веб-сайт или автономное мобильное приложение без службы, требующей аутентификации.
вот мои первоначальные мысли о том, как это будет спроектировано, но нужно проверить, правильно ли это.
- клиент открывает Facebook iOS Login
- пользователь UI входит в систему с учетными данными Facebook и получает маркер доступа
- iOS приложение передает токен доступа к нашему серверу
-
наш сервер разговаривает с FB graph API, используя токен доступа к (a) проверьте маркер и (b) получите идентификатор пользователя FB для этого маркера доступа.
например, наш сервер будет вызывать https://graph.facebook.com/me/?access_token=XYZ который вернет информацию о профиле в объекте JSON
предполагая, что это допустимо, наш сервер извлекает идентификатор пользователя из объекта JSON и проверяет, есть ли у пользователя уже учетная запись. Если это так, мы выдаем наш собственный билет auth клиенту для использования в этом сеансе. Если у пользователя нет учетной записи, мы создайте новый с идентификатором пользователя Facebook, назначьте наш собственный уникальный идентификатор пользователя и выдайте наш билет auth.
клиент проходит авторизацию авиабилет обратно при последующих взаимодействиях, что требуется проверка подлинности.
Это кажется мне правильным подходом, но не уверен, что я упускаю что-то безумно основное и иду по неправильному (сложному) пути.
4 ответа:
Я только что справился с этим сам, и вот часть, которая укусила меня:
в шаге 5... Это возможно для пользователя, чтобы зарегистрироваться для учетной записи с вами полностью отделены от их Facebook ID, не так ли? Затем в другой раз они входят в систему с Facebook.... И вы просто создали им вторую учетную запись и потеряли свою первую.
должен быть способ войти в ваш веб-сервис, а затем войти в facebook и захватить связь между идентификатором facebook и локальная учетная запись.
кроме того, ваш план звучит солидно.
обновление: Facebook добавил документ, описывающий такой сценарий здесь
используйте https для передачи токена аутентификации на ваш сервер, как указано Facebook
совместное использование токенов доступа
наши политики данных явно запрещают любое совместное использование маркера доступа для вашего приложения с любым другим приложением. Тем не менее, мы позволяем разработчикам совместное использование маркеров между собственной реализацией и сервером реализация одного и того же приложения (т. е. используя тот же идентификатор приложения) до тех пор, как передача происходит по протоколу HTTPS.
одна проблема, которую я вижу с этой стратегией, заключается в том, что кто-то может дать вам маркер доступа, полученный для другого приложения facebook. Насколько я знаю, нет никакого способа проверить, что маркер доступа предназначен для вашего приложения, поэтому вы просто продолжите его использовать.
Это звучит не очень вредно, хотя. Обычно люди / приложения пытаются защитить токены доступа, а не делиться ими.
один из возможных эксплойтов этого было бы, для кого-то, чтобы создать свой собственный сайт или мобильное приложение, получать маркеры доступа для своих пользователей и попытаться расшифровать их, используя свой API. Если это удастся (у пользователя есть учетная запись facebook на вашем сайте), вредоносный сайт сможет использовать ваш API, олицетворяющий пользователя.
Это немного длинный выстрел, но я думаю, что это может сработать.
Edit: похоже, что есть способ проверить маркер доступа в конце концов. Смотрите ответ @Daaniel на вопрос получить идентификатор приложения из маркера доступа пользователя (или проверить исходное приложение для токена).
ваше решение работает.
может быть, альтернатива: почему бы просто не получить электронную почту на клиенте от первоначального запроса социальной службы и отправить на ваш веб-сервис? Веб-служба может просто хранить электронную почту и, возможно, social_provider. Я понимаю, что ваш веб-сервис не сможет проверить, откуда пришло письмо, но разве между вашим веб-сервисом и вашим клиентом нет отношений высокого доверия? Если есть, похоже, вы можете зависеть от электронной почты иду из нужного места. Кто-то, пожалуйста, дайте мне знать, какую очевидную вещь я упускаю, что делает подход на основе электронной почты глупым...