Restful API, как приложение может (повторно) сопоставить пользователя с существующим?

Я задавал различные вопросы о своей проблеме (здесь и здесь), и я также спросил на канале #oauth & #openid freenode в IRC. (это обратите внимание на вопрос «ВВЕРХ», это другая проблема)

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

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

Я много гуглил и с помощью предыдущих ответов взглянул на OAuth.

Насколько я понял, как работает OAuth, вот как:

  • Пользователь посещает приложение, использующее мой API (веб, мобильное приложение и т. д.)
  • Приложения перенаправляют пользователя на API для аутентификации (я буду использовать OpenId) и авторизации (OAuth). Это немного странно, так как API будет иметь веб-интерфейс для входа и авторизации (я полагаю, так это работает с Twitter сделать это)
  • API перенаправляет подключенного пользователя в приложение с некоторыми токенами. В этих токенах есть токен, представляющий пользователя, который приложение должно хранить, чтобы указать API, какой пользователь использует его в данный момент (правильно ли я?)

Пока все идет хорошо. Но чего я не могу понять, так это когда пользователь выходит из приложения и снова заходит: как приложение может запомнить, что пользователь использовал его раньше?

(Прежде чем некоторые из вас принесут мне ответ cookie, я отмечу, что это простой пример, это будет то же самое, если пользователь очистит свои файлы cookie, отформатирует свой компьютер или изменит свой компьютер .)

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

Это правильный и безопасный способ сделать это?

IRC-канал #OAuth рассказал мне о новом протоколе WebID, но в настоящее время он находится в режиме предварительного проекта, и я не хочу использовать что-то, что будет постоянно меняться в будущем :/

Спасибо большое за помощь!


oauth openid restful-authentication remember-me
person Cyril N.    schedule 23.12.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Короткий ответ: OAuth создает маркер доступа с проверкой подлинности. Этот токен доступа привязан к ОДНОМУ пользователю. И пока токен доступа действителен. Третье приложение может делать все, что API разрешает токену доступа.

Длинный ответ. Суть OAuth в том, что он не выполняет вход пользователя. OAuth предоставляет сторонним приложениям так называемые токены доступа, которые можно использовать для доступа к данным от имени пользователя, независимо от того, зарегистрирован он или нет.

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

У большинства поставщиков API есть функция отзыва токенов доступа. Вот что происходит, когда вы в Твиттере просматриваете свою страницу "Подключения" . Видите ссылки для отзыва доступа? Отмена доступа к приложениям в Twitter

Лично мне нравится подход OAuth. Как поставщик API, вы можете контролировать, что разрешено делать токенам доступа, а пользователь может убивать плохие приложения, используя его/ее ресурсы. OAuth безопасен с точки зрения аутентификации. Сторонние приложения не получают пароли пользователей. Но после аутентификации они могут делать все, что позволяет ваш API.

person Jon Nylander    schedule 31.12.2010
comment
Спасибо за ваш ответ, я ценю. Я понимаю, как работает OAuth, но мой вопрос был о том, что происходит, когда стороннее приложение теряет токен. Например, когда пользователь очищает все свои файлы cookie, стороннее приложение должно будет повторно подключить его, но как оно может это сделать, если оно не хранит пользовательские данные (если токен доступа напрямую сохраняется в файле cookie пользователя)? Спасибо за вашу помощь! - person Cyril N.; 03.01.2011
comment
Извините за задержку с ответом. Если вы сохраните токен доступа в файле cookie, вам придется получить новый (пользователь должен снова пройти процесс OAuth). Но если у вас есть собственная пользовательская система, вы можете сохранить токен доступа к API для пользователя, чтобы доступ был восстановлен, как только он снова войдет в вашу службу. - person Jon Nylander; 25.03.2011

arrow_upward
1
arrow_downward

если мы посмотрим, как работает Twitter, я думаю, что недостающим моментом является еще один слой проекта: Официальный сайт:

альтернативный текст

Дело в том, что когда вы хотите разрешить любому стороннему приложению использовать Twitter, это приложение перенаправляет вас на страницу OAuth API Twitter, если вы подключены, но если вы не подключены, оно перенаправляет вас на страницу входа, который находится по адресу http://api.twitter.com/login (я не знаю, правильно хранить API в api.twitter.com для входа пользователя, а не просто в twitter.com, но это просто семантика)

Итак, рабочий процесс будет таким:

  • Пользователь переходит к стороннему приложению (например, веб-сайту)
  • Эта третья сторона перенаправляет пользователя на API для авторизации.
  • API сначала перенаправляет пользователя на веб-сайт для аутентификации.
  • Официальный сайт перенаправляет Пользователя на провайдера OpenId (или Facebook connect)
  • Аутентификация выполнена (через несколько запросов)
  • Веб-сайт перенаправляет пользователя на API после его успешной аутентификации.
  • Пользователь разрешает/запрещает разрешения, запрашиваемые сторонними приложениями.
  • API возвращается к сторонним приложениям.
  • Пользователь теперь может использовать (или не использовать) приложение.

Эта реализация имеет 2 проблемы:

  • Каждый раз, когда пользователь не аутентифицируется (очищает файлы cookie, подключается с другого компьютера и т. д.), ему придется пройти метод аутентификации, перенаправляясь на официальный сайт, а затем перенаправляясь в стороннее приложение ( API будет прозрачным, так как он уже разрешил приложению доступ к своим данным).
  • Все эти слои, безусловно, потеряли бы пользователя в процессе аутентификации со слишком большим количеством перенаправлений.
  • Возможным решением было бы хранить access_token пользователя, например, в случае мобильного приложения, но с чистым приложением, ориентированным на html/css/js, это невозможно. Логин/пароль в стороннем веб-приложении, который сопоставлял бы пользователя с access_token API, был бы другим решением, например Seesmic (я думаю), но это просто бесполезно (для нас, а не Seesmic): идея отсутствие пароля пользователя становится бесполезным.

Это возможное объяснение, но мне нужно больше подробностей о том, как это возможно, и ваши мысли об этом решении. Будет ли это работать?

(Я добавил это как ответ, так как он (неполный и не совсем уверен, я согласен).

person Cyril N.    schedule 03.01.2011