Как я могу аутентифицировать пользователя из веб-приложения в API?

Question

Кажется, это часто задаваемые вопросы, и, прочитав тонны документации по этому вопросу, я все еще не уверен, что все правильно понял (полагаю, что глупость - это возможный ответ;)).

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

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

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

Но что касается аутентификации, я не могу найти какой-либо ценный пример, учебное пособие, объяснения о том, какреализовать его правильно.

Я (постараюсь) объяснить:

В моем (прекрасном мире счастливых медведей) я структурировал свой проект по различным частям:

• RESTful API
• Веб-приложения, которые будут использовать API.В идеале я думал о создании полного проекта html / css / js, без какой-либо работы на стороне сервера (php / python / java или чего-либо еще)
• мобильное приложение
• Windows / Mac /Linux-приложение

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

• Базовый HTTP (+ желательноSSL) / способ дайджеста
• OAuth
• OpenId

Поскольку я не буду хранить пароль пользователя, первый для меня не будет, а два других оставятМеня смущает.

Но OAuth и OpenId не одно и то же, один (OpenId) обозначает Аутентификация (что является основой вопросов), где второй (OAuth) расшифровывается как Authorization !

Когда Twitter реализует OAuth для своего API, они не внедряют систему аутентификации, существует способ указать своим пользователям, что приложение X хочетиметь доступ к тебеучетная запись ser (на различном уровне доступа).Если пользователь в настоящее время не вошел в Twitter, он сначала должен будет аутентифицировать себя, , а затем авторизовать текущее приложение для доступа к своим данным.

Так что простоЧтобы прояснить ситуацию, OAuth НЕ является механизмом аутентификации , это:

Открытый протокол, разрешающий безопасную авторизацию API (источник: http://oauth.net/)

Тогда единственным способом аутентификации пользователя будет использование OpenId. И тогда, черт возьми, это станет реальностью.

Если я возьму в качестве примера веб-приложение, созданное исключительно из html / css / jsбез серверных компонентов обмениваться данными с API.

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

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

Это здорово, теперь веб-приложение знает, что пользователь действительно мистер X. Но API все еще имеет какое-то представление!

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

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

формат отредактирован

Answer 1

Вы действительно не хотите входить в API, используя OpenID.Как вы сказали, OpenID для Аутентификация , т.е. Кто, в то время как OAuth для Авторизация , т.е. мне разрешено?Но ваша структура предполагает, что вы будете использовать API в качестве бэкэнда и веб-приложение в качестве внешнего интерфейса.

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

Принципиальное отличие OpenID от OAuth заключается в его использовании.В вашей ситуации у вас может быть что-то подобное:

--------          ---------            -------
| User | <------> |  App  | <--------> | API |
--------  OpenID  ---------   (OAuth)  -------

Пользователь никогда не взаимодействует напрямую с API: кто захочет отправить HTTP-запрос вручную?(lol) Вместо этого сервис предоставляется через приложение, которое может быть дополнительно авторизовано с помощью OAuth.Однако в случае, если одно приложение обращается к API, вы можете установить внутреннее соединение приложения <=> API и никогда не предоставлять его.

Answer 2

(Если вы не хотите читать, список ниже подытожит всю идею)

Возможное решение (скажите, если я ошибаюсь) будет отображать форму входа в систему для потребителя (веб-приложения, мобильные приложения и т. Д.), Пользователь нажимает на своего поставщика (myopenid, Google и т. д.), который открывает всплывающее окно для входа в систему. Сложность в том, что для параметра return_to будет задан API, а не веб-сайт

Затем API повторно отправит check_authentication и получит is_valid: true (или нет). На этом этапе приложение будет запрашивать API-адрес для определенного URL-адреса, который возвращает состояние аутентификации (обработка, сбой, успех). Во время обработки пользователю отображается индикатор (загрузка gif), а в случае успеха / неудачи результат отображается пользователю.

Если API получает is_valid: true, он запрашивает информацию о пользователе на сервере openid, такую ​​как электронная почта, имя, фамилия, и сравнивает их с базой данных своего пользователя. Если есть совпадение, API создает сеанс между собой и приложением, если пользователь новый, он создает новую запись, а затем сеанс.

Сеанс будет уникальным токеном с определенной продолжительностью (может быть равным продолжительности openid server assoc_handle?)

Кажется, это возможно, но я не специалист по безопасности.

Чтобы объяснить вещи проще, вот небольшая «карта»:

Примечание. Поставщик - это сервер OpenId (который предоставляет информацию об аутентификации)

• Пользователь заходит в веб-приложение и нажимает на значок входа в систему своего провайдера (Google for ex)
• В веб-приложении открывается всплывающее окно, содержащее страницу входа и страницу доступа провайдера, и задайте return_to для API
• Провайдер отправляет информацию в Api
• API проверяет эти данные с помощью check_authentication
• Если код недействителен, API указывает веб-приложению (которое запрашивает API каждые x секунд) об ошибке
• Если он действителен, Api запрашивает информацию о пользователе у провайдера, например, электронную почту, отображаемое имя и т. Д.
• Если пользователь существует, создается сеанс
• Если пользователь новый, он добавляется в базу данных и создается сеанс
• Api возвращает состояние аутентификации (в данном случае успешное завершение) с сеансом токена, который будет использоваться веб-приложением для дальнейших запросов.