OAuth2 "социальный вход" (разрешить проверку подлинности OAuth2 через Facebook/Twitter): есть ли примеры/литература?

Я разрабатываю собственное мобильное приложение для настраиваемого веб-приложения для социальных сетей. Мы создаем REST API для связи с веб-сервером, и мы выбрали OAuth2 в качестве метода аутентификации (поток grant_type=password).

Веб-приложение позволяет пользователям регистрироваться и регистрироваться с помощью внешних сервисов (например, Facebook и Twitter). Мы должны разрешить то же самое и в мобильном приложении. Вопрос в том, как мы можем это сделать?

Мобильное приложение Pinterest может управлять ситуацией (см. прикрепленное изображение). Каков поток, который использовался здесь?

Они ведут себя как классическое приложение, основанное на OAuth (мобильное приложение, действующее как клиент OAuth напрямую с API Facebook?). Если да, то как мобильное приложение может быть аутентифицировано с помощью Pinterest-сервера? Передает ли он токен доступа OAuth Facebook в качестве учетных данных?

Графическое представление проблемы (см. стрелку ????):

Website API                 Mobile app                    Facebook OAuth

  +                           +                               +
  |                           |                               |
  |                           |       /oauth2/token           |
  |                           +------------------------------>|
  |                           |                               |
  |                           |       OAuth Access Token      |
  |                           |<-----------------------------+|
  |                           |                               |
  |           ????            |                               |
  |- - - - - - - - - - - - - -|                               |
  |                           |                               |
  |                           |                               |
  |    OAuth Access Token     |                               |
  |+------------------------->|                               |
  |                           |                               |
  |                           |                               |
  |   API Usage (w/ token)    |                               |
  |+------------------------->|                               |
  |<-------------------------+|                               |
  |                           |                               |
  |+------------------------->|                               |
  |<-------------------------+|                               |
  |                           |                               |
  |           ...             |                               |
  +                           +                               +

Обновление: Этот вопрос очень похож на мой.. Если это правильный путь, чтобы следовать, то второй + третий шаг (передача токена Facebook в наш пользовательский API плюс проверка самого токена) не может быть дополнительным типом предоставления OAuth2 (т.е. facebook_token)?

Ответ 1

Вы можете попробовать использовать маркер доступа fb, который вы только что получили на своем мобильном устройстве. (может быть любой другой провайдер). Отправьте его на свой сервер в службу входа/регистрации/оба веб-сервиса. На стороне сервера вы можете проверить, кто пользователь, используя fb sdk и токен доступа, войдите в систему и отправьте ему файл cookie/сеанс.

Ответ 2

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

Во-первых: методология проверки подлинности зависит от поставщиков, которых вы хотите поддержать.

Несколько показаний, которые могут уточнить:
http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing http://openid.net/get-an-openid/what-is-openid/
http://blog.bobcravens.com/2010/08/openid-and-oauth-using-dotnetopenauth-in-asp-net-mvc/ http://stackoverflow.com/questions/7996124/how-to-authorize-mobile-apps-with-a-third-party-by-oauth-but-connect-to-my-servi

Общий рабочий процесс аутентификации:
1. Веб-приложение начинается с представления области, которая позволяет пользователю выбирать между различными поставщиками OpenID/OAuth.
2. Ваше приложение перенаправляется на сервер провайдеров (после того, как вы добавили некоторую информацию о приложении к почтовым данным - подробности см. В описании API-интерфейса поставщика). И OpenID, и OAuth используют серию перенаправлений для аутентификации пользователя. Ключ заключается в том, что аутентификация происходит на сайте провайдеров, и там, где хранятся пароли.
3. Пользователь регистрируется в выбранном провайдере, затем происходит новое перенаправление на ваш сайт (через механизм URL-адреса обратного вызова).
4. Это перенаправление включает в себя информацию об аутентифицированном пользователе, которая предоставляется поставщиками OpenID/OAuth. Как минимум, перенаправление отправляет "имя пользователя" обратно в ваше приложение.
5. Используйте эту информацию, чтобы проверить, может ли аутентифицированный пользователь войти на ваш сайт.

Ответ 3

Стефано

Для этого мы используем StackMob. Он работает очень хорошо и очень просто реализовать.

SDK StackMob предлагает защиту и аутентификацию OAUTH2 через Facebook и Twitter.

Обновить: StackMob больше не существует с мая 2014 года

Ответ 4

Создайте различные идентификаторы клиента OAuth для своих поставщиков социальных услуг.

Пример:

Facebook - ID клиента №1 Twitter - ID клиента # 2

Создайте свои общедоступные маршруты для ваших социальных потоков.

Пример:

http://www.test.com/auth/facebook/ http://www.test.com/auth/facebook/callback/

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

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

Сначала они (клиент) должны пройти процесс социального входа в систему, как описано ранее.

Затем на успешном обратном вызове социального провайдера вам нужно будет отобразить интерфейс (возможно, на веб-сайте) клиенту, позволяющий им принимать/отклонять объем прав, запрашиваемых третьей стороной. На начальном бите социального входа вам придется явно пройти длинный или сохранить запрашиваемую третьей стороной долю, чтобы передать ее для этапа обратного вызова социального провайдера.