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

Question

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Большинство провайдеров API имеют функции для отзыва токенов доступа.Вот что происходит, когда вы в твиттере смотрите на страницу Connections .Смотрите ссылки отзыва доступа?

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