Защита REST API

Question

Я занимаюсь разработкой веб-приложения для социальных сетей на PHP, которое будет поддерживаться различными веб-сервисами, каждый из которых работает с REST API. Web-сервисы, вероятно, будут реализованы в Java с уровнем данных MySQL, но суть того, что я пытаюсь сделать, - это сделать их действительно простыми для реализации модулей в разных языках / хранилищах данных в зависимости от того, что ценится.

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

Другим примером может быть, если пользователь отправляет личное сообщение другому пользователю. Сообщение будет отправлено в веб-службу личных сообщений, которая позаботится обо всем хранилище. Аналогично, с веб-службой можно связаться для получения сообщений для пользователя.

Хотя я понимаю, как реализовать веб-сервис REST в Java и установить соединение с ним в PHP, я совершенно не уверен в том, как защитить передаваемые данные и убедиться, что это возвращаемые данные пользователей. Например, если я хочу получить все пользовательские личные сообщения, как веб-служба узнает, что вернуть этих пользователей. Я мог бы передать этот идентификатор пользователя как часть URL-адреса GET, но тогда наверняка любой старый пользователь мог бы просто выяснить URL-адрес GET и использовать его для поиска сообщений других людей. Я подумал, что, возможно, смогу передать идентификатор сеанса и IP-адрес, который позволил бы мне проверить хранилище данных сеанса и убедиться, что это правильный пользователь?

Чтобы защитить важные данные, такие как имя пользователя / пароль, я подумал, что просто передам их по SSL.

Надеюсь, это лучше объясняет мою проблему.

Спасибо

Answer 1

Посмотрите на HTTP Digest аутентификацию. Большинству клиентов следует поддерживать его, и это означает, что данные аутентификации могут быть безопасно переданы с каждым запросом как часть заголовков, не влияя на полезную нагрузку самого запроса.

Answer 2

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

Answer 3

Имейте в виду, что ваш API должен имитировать протокол HTTP.

Http не имеет состояния, и добавляя какие-либо сеансы или около того, вы пытаетесь подделать метод Alwaysconnected.

При использовании LoginForm мне нужно будет отправить два запроса на каждый звонок;)

Answer 4

Это в основном 2 вопроса.

Когда речь идет о конфиденциальности, я бы выбрал самый безопасный вариант: обслуживать данные по SSL (через HTTPS).

Что касается аутентификации, существует несколько возможностей.Basic over SSL является одним из них, но простой формой входа с cookie может быть другой.(Например, ASP.Net Forms Authentication.) Все зависит от того, как вы хотите реализовать свой механизм аутентификации.