Защита моего API только для работы с моим интерфейсом

Question

Я строю узел/экспресс-сервер. Я хочу создать API, который работает только с моим внешним интерфейсом (private API).

Представьте, что если это веб-сайт электронной коммерции, мои пользователи будут просматривать продукты, а затем выбирать, что покупать, и в момент заказа они могут или не могут войти в систему.

Какова наилучшая практика, чтобы убедиться, что мои API будут работать только с моим интерфейсом?

Что происходит, когда пользователи решают войти или остаются в качестве гостей?

Answer 1

Итак, один из способов сделать. При отправке любых запросов AJAX на ваш сервер отправьте заголовок, который содержит некоторые клавиши типа apiKey: «some key». На сервере всякий раз, когда вы его получаете, и аутентифицируете домен, на котором подано ваше приложение-ответ. Если нет, вам не нужно отвечать. Что-то вроде

app.get('/route', function(req, res) { 
    if(req.headers.apiKey == "some key) // respond with success 
    // respond with 401 Forbidden 
}); 

Таким образом, любой запрос, который попадает на сервер, должен иметь apiKey, чтобы я работал.

Answer 2

Применить CORS - сервер определяет домены, разрешенные для запроса вашего API.

Как это работает?

1. Клиент отправляет специальный запрос «предполетный» (метод OPTIONS) на сервер, спрашивая, входит ли запрос домена, среди разрешенных доменов. Он также спрашивает, является ли метод запроса OKAY (вы можете разрешить GET, но отрицать POST, ...).
2. Сервер определяет, разрешать или запрещать запрос. Он отвечает «ОК» и устанавливает специальные заголовки, которые указывают, какие домены/методы запроса разрешены.
3. Если клиент имеет право опрашивать API, он выполняет запрос предназначен, или вываливается ...

Клиенты, которые уважать CORS (браузеры) будет (или не будет, если отказано) в состоянии подключения. Если клиент игнорирует CORS (клиент REST, инструменты CLI, ...) будет иметь возможность подключиться ни на что ...

Тем не менее, требует подписанных запросы (авторизация)

Answer 3

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

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

Протокол, который вы хотите использовать для защиты вашего приложения React и API бэкэнд, является потоком предоставления пароля OAuth2. То, как это работает в теории, довольно просто.

В вашем приложении React вы собираете имя пользователя/пароль пользователя (это также может быть адрес электронной почты/пароль, если вы структурировали свое приложение).

Вы затем отправить запрос POST к вашему бэкэнду API, который выглядит примерно так:

POST api.myapp.com/oauth/token 

grant_type=password&username=USERNAME&password=PASSWORD 

Убедитесь, что вы используете тип application/x-www-form-urlencoded содержимого при отправке сообщений на сервер.

После этого сервер выполнит этот запрос, запустит его через библиотеку OAuth2 и сгенерирует токен 2 и токена и обновления.

После того, как вы получили маркеры, сгенерированные на вашем API-интерфейсе на стороне сервера, вы затем сохраните эти токены в cookie, которые затем будут храниться в браузере пользователя.

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

Вы должны будете использовать библиотеку OAuth2 для серверной стороны, так как это будет обрабатывать такие вещи, как:

• порождающих лексемы.
• Обмен токен обновления для нового токена доступа, когда он истекает.
• Идентификация пользователя на основе токенов.
• отменив лексемы, если они скомпрометированы, и т.д.

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

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

Использование потока, упомянутого выше, вместо гораздо безопаснее, так как вы получаете много защиты:

• Нет постоянных учетных данных, хранящихся в небезопасном месте.
• В качестве идентификаторов используются недолговечные токены. Они вращаются со временем.
• Токены хранятся в файлах cookie, которые НЕ доступны для Javascript. Это означает меньший риск воздействия на сеть.
• Пароль только раз обменять на время сеанса - это означает, что менее чувствительная информация собирается через провод реже =)

В любом случае: надеюсь, что это помогает!

И, если вы ищете некоторые инструменты, любая библиотека oauth (серверная сторона) должна помочь вам в этом. Если вы ищете услугу, которая может это сделать для вас, вы можете проверить продукт, над которым я работаю (Stormpath). Это платная услуга, но для вас большая часть этой сложности.

Answer 4

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

Есть несколько простых способов, которые обычно используются для решения этой проблемы:

Embedded Secret

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

Если вы подумывали о среде, где у вас были другие варианты выбора языка, вы можете сделать больше, чтобы запутать секрет в своем приложении (например, используя NDK в Android). Javascript сложно.

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

Ограничение скорости

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