Как люди обрабатывают аутентификацию для RESTful API (независимой от технологии)

Question

Я смотрю на создание мобильных приложений. Поэтому эти приложения будут «общаться» с моим сервером через JSON и REST (например, put, post и т. Д.).

Если я хочу убедиться, что приложение клиентского телефона пытается сделать что-то, что требует некоторого «разрешения», как люди справляются с этим?

Например:

На нашем сайте продаются вещи -> телевизоры, машины, платья и т. Д. позволяют людям просматривать магазин и покупать вещи. Чтобы купить, вам нужно быть "авторизованным". Мне нужно убедиться, что человек, который использует их мобильный телефон - это действительно они.

Как это можно сделать?

Я посмотрел на то, как твиттер делает это с их OAuth .. и похоже, что у них есть несколько значений в ЗАПРОСЕ ЗАПРОСА? Если это так (и мне нравится этот подход), возможно ли, что я могу использовать другую стороннюю компанию в качестве веб-сайта для хранения имени пользователя / пароля (например, Twitter или Facebook являются поставщиками OAuth) ... и все, что я делаю, это как-то получаю пользовательские данные заголовка .. и убедитесь, что они существуют в моей базе данных .. еще .. заставить их пройти аутентификацию у своего поставщика OAuth?

Или есть другой способ?

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

Answer 1

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

Если это действительно требование, вам нужно хранить идентификационные данные пользователей в своей системе.Самая популярная форма отслеживания личности - через имя пользователя и пароль.

Я посмотрел, как это делает твиттер с их OAuth .. и похоже, что они имеют несколько значений вЗАПРОСИТЬ ЗАГОЛОВОК?Если это так (и мне нравится этот подход), возможно ли, что я могу использовать другую стороннюю компанию в качестве веб-сайта для хранения имени пользователя / пароля (например, Twitter или Facebook являются поставщиками OAuth) ... и все, что я делаю, это как-то извлекаюпользовательские данные заголовка .. и убедитесь, что они существуют в моей базе данных .. еще .. заставить их проходить аутентификацию у своего поставщика OAuth?

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

Что касается заявленных вами требований, вы определенно можете посмотретьпри интеграции Open ID в ваше приложение.Есть много библиотек, доступных для интеграции, но поскольку вы попросили дать независимый ответ, я не буду перечислять ни одну из них.

Или есть другой способ?

Конечно,Вы можете хранить идентификаторы пользователей в своей системе и использовать basic или digest аутентификацию для защиты вашего API.Базовая аутентификация требует только одного (легко вычисляемого) дополнительного заголовка для ваших запросов:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

Answer 2

Поскольку службы RESTful используют HTTP-вызовы, вы можете ретранслировать Базовая аутентификация HTTP в целях безопасности.Это просто, прямо и уже поддерживается для протокола;и если вы не хотите дополнительной безопасности в транспорте, вы можете использовать SSL.Хорошо зарекомендовавшие себя продукты, такие как IBM Websphere Process Server, используют этот подход.

Другой способ - создать собственную структуру безопасности в соответствии с потребностями вашего приложения.Например, если вы не хотите, чтобы ваш сервис использовался только определенными устройствами, вам, возможно, потребуется отправить закодированный токен в качестве заголовка через провод, чтобы убедиться, что запрос поступил из авторизованного источника.У Amazon есть интересный способ сделать это, вы можете проверить это здесь .