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

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

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

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

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

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

Я попробую объяснить:

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

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

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

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

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

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

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

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

Открытый протокол для обеспечения безопасного API авторизация (источник: http://oauth.net/)

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

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

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

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

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

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

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

-edited format

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Кажется, что-то возможно, но я не эксперт в области безопасности.

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

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

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

Ответ 2

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

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

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

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

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