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

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

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

Например:

Наш сайт продает вещи → tv's, car's, dresses и т.д. Api будет позволяют людям просматривать магазин и приобретать предметы. Чтобы купить, вам нужно "войти в систему". Мне нужно убедиться, что человек, который использует их мобильный телефон, на самом деле они.

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

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

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

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

Ответ 1

Наш сайт продает вещи → tv's, car's, dresses и т.д. Api будет позволяют людям просматривать магазин и приобретать предметы. Чтобы купить, вам нужно "войти в систему". Мне нужно убедиться, что человек, который использует их мобильный телефон, на самом деле они.

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

Я посмотрел, как твиттер делает это с OAuth.. и это похоже, что у них есть ряд значений в REQUEST HEADER? Если так (и я вроде как этот подход), возможно ли, что я могу использовать другой третьей стороной в качестве веб-сайта для хранения имени пользователя/пароля (например. Twitter или Facebook - поставщики OAuth).. и все, что я делаю, это каким-то образом получить пользовательские данные заголовка.. и убедиться, что он существует в my db.. else.. заставить их аутентифицироваться с помощью своего поставщика OAuth?

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

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

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

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

Ответ 2

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

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