Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

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

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

Роли:

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

Поток:

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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