Защита моего API-интерфейса REST API Node.js?

Я мог бы помочь с помощью REST API. Я пишу приложение Node.js, которое использует Express, MongoDB и имеет Backbone.js на стороне клиента. Я провел последние два дня, пытаясь выработать все это и не очень повезло. Я уже проверил:

Я хочу, чтобы мой backend и frontend были как можно более раздельными, поэтому я подумал об использовании тщательно разработанного REST API. Мое мышление заключается в том, что если я когда-нибудь займусь разработкой приложения для iPhone (или чего-то еще подобного), он сможет использовать API для доступа к данным.

НО, я хочу, чтобы это было безопасно. Пользователь зашел в мое веб-приложение, и я хочу, чтобы мой API был безопасным. Я читал об OAuth, OAuth 2.0, OpenID, Hmac, хэшах и т.д. Я хочу избежать использования внешнего входа в систему (Facebook/Twitter/etc). Я хочу, чтобы регистрация и вход в систему выполнялись на моем приложении/сервере.

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

Любая помощь, любая информация, любые примеры, шаги или что-то было бы замечательно. Пожалуйста, помогите!

ОТВЕТЫ

Ответ 1

Здесь другой способ думать об этом:

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

Теперь мне кажется, что единственное, что вы меняете здесь, это способ доставки информации. Вместо предоставления информации в виде HTML, вы возвращаете информацию как JSON и визуализируете ее на стороне клиента. Ваши запросы AJAX на сервер будут иметь тот же входной токен, что и раньше, поэтому я предлагаю просто проверить этот токен и ограничить информацию до "того, что пользователю разрешено знать" таким же образом.

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

Точка систем, таких как OAuth, должна предоставлять этот метод "входа в систему", как правило, из стороннего приложения и как разработчика. Это потенциально может быть хорошим решением для iPhone-приложения или подобного, но в будущем. Нет ничего плохого в том, что API принимает несколько методов аутентификации!

Ответ 2

В порядке повышения безопасности/сложности:

Базовый HTTP-аутентификация

Многие библиотеки API позволят вам построить это в (например, в порте в Django), или вы можете позволить своему веб-серверу справиться с этим. Оба Nginx и Apache могут использовать серверные директивы для защиты сайта с помощью простого пароля b64encoded. Это не самая безопасная вещь в мире, но это, по крайней мере, имя пользователя и пароль!

Если вы используете Nginx, вы можете добавить раздел в конфигурацию своего хоста, например:

auth_basic "Restricted";
auth_basic_user_file /path/to/htpasswd;

(Поместите его в блок location /)

Документы: http://wiki.nginx.org/HttpAuthBasicModule

Вам нужно будет получить python script, чтобы сгенерировать этот пароль и поместить вывод в файл: http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt p >

Расположение файла не имеет большого значения, пока Nginx имеет к нему доступ.

HTTPS

Закрепите соединение с вашим сервером в приложении, это самый простой и предотвратит попадание человека в средние атаки.

Вы можете сделать это с помощью Nginx, документы для него очень полные: http://wiki.nginx.org/HttpSslModule

Самозаверяющий сертификат для этого будет хорошим (и бесплатным!).

Ключи API

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

OAuth

OAuth 2.0 - это тот, который стоит здесь. В то время как я не знаю, как работает эта спецификация, это стандарт defacto для большей аутентификации (Twitter, Facebook, Google и т.д.), И есть тонна библиотек и документов, которые помогут вам реализовать их. При этом обычно используется для аутентификации пользователя путем запроса стороннего сервиса для аутентификации.

Учитывая, что вы делаете разработку в обоих концах, вероятно, этого будет достаточно, чтобы поместить ваш API за Basic HTTP Auth и обслуживать его через HTTPS, особенно если вы не хотите тратить время на использование OAuth.

Ответ 3

Ответы до сих пор отлично справляются с объяснением, но не дают никаких реальных шагов. Я столкнулся с этим сообщением в блоге, в котором подробно рассказывается о том, как безопасно создавать и управлять маркерами с помощью Node + Passport.

http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/