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

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

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

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

источник

2009-02-13 Alex Wayne

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

процесс будет что-то вроде этого:

Роли:

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

потока:

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

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

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

источник

2009-02-17 03:50:08

Спасибо за это фантастическое объяснение. –

Я ищу такие же объяснения, и ваш ответ значительно улучшился, но там, где мне не хватает информации, между 5 и 6. Ваш «протокол OAuth ** magic **» мне не помогает много: p Возможно ли, что вы дадите мне (нам?) более подробную информацию о том, где происходит волшебство, как спокойный сервер уверен, что у ненадежного потребителя есть официально зарегистрированный пользователь? Большое спасибо! –

Это «магия OAuth» заботится о хорошей библиотеке OAuth или читает спецификацию и реализует ее самостоятельно, но, короче говоря, потребитель отправляет окончательный запрос поставщику услуг с «кодом верификатора», в ответ на который поставщик услуг отправляет потребителю «токен доступа», который он может использовать для подписания последующих разрешенных запросов. –

См: это related question

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

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

источник

2009-02-13 01:41:17

Могу ли я использовать OAuth в качестве потребителя OpenID, полагая, что у нас уже установлена учетная запись? или провайдер должен его поддерживать? –

В OpenID есть две роли: «OpenID Provider» и «Relying Party». В OAuth есть две роли: «Поставщик услуг» и «Потребитель». Это сбивает с толку, потому что в OpenID 1.1 доверяющая сторона называлась Consumer. В любом случае, провайдер OP не должен поддерживать OAuth. См. Мой собственный ответ. –

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

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

источник

2009-02-13 01:52:54 yungchin

Это неточно. OpenID об аутентификации пользователей - это не исключает других средств аутентификации/авторизации для доступа к API. Вот что такое OAuth. –

Я просто отвечаю на вопрос: «Если бы я хотел разрешить пользователю OpenID аутентифицироваться против API для использования в альтернативных клиентах ...» - это вы не можете контролировать: поставщик управляет режимом взаимодействия, а не потребителем. Вы говорите, что сами в своем решении тоже ... – yungchin

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

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

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

источник

2009-08-26 21:28:59

ответ

Смежные вопросы