Рекомендации по безопасным API-интерфейсам?

Question

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

1) Вытягивание данных из вызовов AJAX, возвращающих данные в прохладном виде, JavaScripty-ways 2) Создание приложений iPhone, которые используют эти данные; 3) Наличие других веб-приложений использует эти данные для их собственного конца.

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

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

Итак, мой вопрос: после некоторого времени осмотреть Oauth и OpenID, я не уверен, что есть решение, которое будет обрабатывать все три из вышеперечисленных. Есть ли какие-то канонические «лучшие практики» для ключей разработчиков, или может ли Oauth и OpenID обрабатывать AJAX-вызовы легко в некотором роде, которые мне еще предстоит получить, или я чего-то не хватает?

Answer 1

Я думаю, что 2-позиционный OAuth - это то, что вы хотите удовлетворить # 2 и № 3. Для # 1 я бы предположил, что вместо того, чтобы клиент запрашивал JS-запросы непосредственно против вашего приложения, они могли вместо этого проксировать эти запросы через свое собственное веб-приложение.

Answer 2

Среднее решение должно требовать ключа API; а затем потребовать, чтобы тот, кто его использует, фактически не использует его непосредственно с AJAX; но завернуть их звонки в запросе на стороне сервера, например:

AJAX -> customer server -> your server -> customer server -> user 

Создание простого PHP API для заинтересованных сторон не должно быть слишком сложным, и ваши собственные приложения iPhone, очевидно, вырезать среднего человека, перевозка груза с их собственный ключ API.

Answer 3

OAuth и OpenID вряд ли будут иметь отношение к прямым вызовам AJAX. Скорее всего, у вас будет какой-то фильтр авторизации перед вашим обработчиком AJAX, который проверяет файл cookie, и, возможно, этот файл cookie устанавливается в результате проверки OpenID.

Похоже, что это сводится к вопросу о «how do I prevent screen scraping». Если только зарегистрированные пользователи могут увидеть цены, это одно, но если вы считаете, что вы похожи на большинство торговых площадок, и ваш барьер для подписки на клиента как можно ниже, это на самом деле не помогает.

И, эй, если ваши цены не являются доступны, вы не можете появляться в поисковых системах, таких как Froogle или Nextag или PriceGrabber. Но это скорее решение бизнес-стратегии, а не программирование.