dailymotion Аутентификация OpenID и доступ к API




dailymotion embed (4)

Аутентификация OpenID по своей сути основана на браузере. Если бы я хотел, чтобы пользователь OpenID аутентифицировался против API для использования в альтернативных клиентах, существует ли для этого лучшая практика?

Например, если пользователь попытался войти в свой OpenID в приложение для iPhone, например, как это будет работать? Единственное, что я могу придумать для создания маркера API для них и заставить пользователя вручную ввести его где-нибудь. Этот подход не является удобным для пользователя.

Именно так работают сайты, такие как Basecamp , но мне все еще кажется неуклюжим.


См .: этот связанный вопрос

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

Надеемся, что больше провайдеров найдут OAuth . В качестве альтернативы вы можете передать код аутентификации нескольким более крупным сайтам.


То, что вы хотите, невозможно с OpenID. OpenID основан на предпосылке, что вы (приложение iPhone) хотите узнать только о своих пользователях, которым доверяет их поставщик OpenID. Они никогда не аутентифицируются для вас.

Хорошие поставщики OpenID на самом деле даже препятствуют тому, чтобы вы опосредовали процесс аутентификации (так как это подвергло вас пользователям возможную атаку!): Они требуют, чтобы пользователи входили в систему с ними напрямую и отказывались от входа в систему.


Ни OpenID, ни OAuth не определяют, как пользователь аутентифицируется. Они определяют, как потребитель направляет агент пользователя поставщику аутентификации, как перенаправляется пользовательский агент и как потребитель может проверить личность, которую пользователь аутентифицировал.

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

Существуют различия между OpenID и OAuth, но оба требуют, чтобы потребитель использовал HTTP-перенаправления и обратные URL-адреса. Они оба основаны на браузере. Если ваше приложение говорит HTTP, оно может сделать это. Однако главное, что пользователь вводит учетные данные только в доверенное приложение.


Проблема, которую вы видите, не уникальна для OpenID. У этой проблемы может быть любая схема аутентификации без пароля. OAuth ( http://oauth.net/ ) - это решение, которое является открытым стандартом, который быстро набирает силу на многих веб-сайтах. Он полностью независим от того, как пользователь аутентифицируется, поэтому их провайдеру OpenID не нужно поддерживать или даже знать, что ваш сайт («поставщик услуг» в терминах OAuth) использует OAuth. Ваш клиент API может быть веб-сайтом или даже локальным приложением!

Процесс будет примерно таким:

Роли:

  • пользователь: тот, у кого есть учетная запись на вашем веб-сайте.
  • поставщик услуг: ваш веб-сайт с программным API, для которого требуется доступ к определенным учетным данным.
  • потребитель: клиент, будь то веб-или локальное приложение, которому необходим доступ к API-интерфейсу поставщика услуг.

Поток:

  1. Пользователь находится у потребителя. Он указывает, что хочет получить доступ к данным у поставщика услуг.
  2. Пользователь перенаправляется (если пользователь является веб-сайтом) или появляется браузер (если потребитель является локальным приложением), и пользователь видит веб-сайт поставщика услуг.
  3. Пользователь либо уже зарегистрирован в Поставщике услуг через постоянный файл cookie, либо пользователь должен сначала войти в Поставщик услуг, но это сделано (OpenID в вашем случае).
  4. Затем поставщик услуг спрашивает пользователя: «Потребитель (какой-то потребитель) хочет получить доступ к вашим данным (или нашему API или тому подобное). Вы хотите разрешить это? (Да / нет)
  5. Пользователь подтверждает, и окно браузера закрывается или перенаправляется обратно на сайт Consumer.
  6. Через некоторую магию протокола OAuth у потребителя теперь есть секретный учет, который он может использовать для доступа к вашему API и доступа к любой пользовательской личной информации, которую вы только что разрешили.

Очевидно, я не могу включить здесь всю спецификацию OAuth, но вы можете надеяться, что это решит вашу проблему. Библиотеки OAuth существуют, чтобы упростить добавление поддержки.

Если вы используете ASP.NET, я предлагаю http://dotnetopenid.googlecode.com/, поскольку он недавно добавил поддержку OAuth (v3.0 beta 1).





openid