Защита REST API

Question

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

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

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

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

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

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

Thanks

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Http не имеет гражданства, и, добавив любые сеансы или около того, вы пытаетесь подделать метод «Alwaysconnected».

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