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

Мета: Дозволити користувачеві пройти автентифікацію з Facebook в додатку iOS, який вимагає доступу до захищеної веб-служби, яку я запускаю.

Припущення: Для тих користувачів, які вирішили не використовувати Facebook для входу, існує система нативного аутентифікації (та реєстрації).

Деталі:

• Припустимо, ми хочемо запропонувати користувачеві можливість входити через Facebook без створення окремого облікового запису / облікових даних для нашої системи.
• Оскільки ми підтримуємо власний власний механізм аутентифікації (ім’я користувача та пароль), ми маємо власні ідентифікатори користувачів та видаємо маркер автентифікації, який використовується для наступних взаємодій після первинної перевірки облікових даних.

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

Ось мої початкові думки щодо того, як це було б розроблено, але хочу перевірити, чи правильно це.

1. Клієнт вискакує логін Facebook iOS
2. Користувач інтерфейсу користувач входить за допомогою облікових даних Facebook та отримує маркер доступу
3. Додаток iOS передає маркер доступу на наш сервер

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

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

5. Припустимо, що він дійсний, наш сервер витягує ідентифікатор користувача з об’єкта JSON і перевіряє, чи є у користувача вже обліковий запис. Якщо так, ми видаємо клієнту власний авторський квиток, який він використовуватиме для цього сеансу. Якщо у користувача немає облікового запису, ми створюємо новий з ідентифікатором користувача Facebook, присвоюємо власний унікальний UserID та видаємо свій авторський квиток.

6. Потім клієнт повертає автентичний квиток на наступні взаємодії, які потребують аутентифікації.

Це здається правильним підходом до мене, але не впевнений, чи мені не вистачає чогось шалено основного та йду по неправильному (складному) шляху.

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

На вашому кроці 5 ... Користувач може зареєструватися у вашому обліковому записі повністю окремо від свого ідентифікатора Facebook, правда? Потім в інший раз вони входять у Facebook .... А ви просто створили їм другий обліковий запис і втратили перший.

Потрібно створити спосіб увійти до свого веб-сервісу, потім увійти до facebook та зафіксувати зв'язок між ідентифікатором facebook та локальним обліковим записом.

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

Оновлення : Facebook додав документ, який окреслює такий сценарій, ТУТ

Використовуйте https, щоб передати маркер аутентифікації на ваш сервер, як заявлено у Facebook

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

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

Одна з проблем, які я бачу в цій стратегії, полягає в тому, що хтось може надати вам маркер доступу, отриманий для іншого програми facebook. Наскільки я знаю, немає можливості перевірити, що маркер доступу відповідає вашій програмі, тож ви просто продовжуєте користуватися ним.

Це здається не дуже шкідливим. Зазвичай люди / програми намагаються захистити маркери доступу, а не ділитися ними.

Одним з можливих подвигів цього може бути те, щоб хтось створив свій власний сайт або мобільний додаток, отримав жетони доступу для своїх користувачів і спробував їх автентифікувати за допомогою свого API. Якщо це вдасться (у користувача на вашому сайті є обліковий запис у Facebook), зловмисний сайт зможе використовувати ваш API, що видає себе за користувача.

Це трохи дальне постріл, але я думаю, що це може спрацювати.

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

ваше рішення повністю працює.

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