Защита API REST

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

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

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

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

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

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

Спасибо

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

С помощью LoginForm мне нравится отправлять два запроса для каждого вызова;)

Ответ 4

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

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

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