REST просит Выполняется авторизация

Question

Я работаю на службы REST, который имеет несколько требований:

1. Он должен быть безопасным.
2. Пользователи не могут подделывать запросы.

Мое текущее предложенное решение иметь пользовательский заголовок Authorization, которые выглядят так (это так же, как амазонка работа веб-сервисы):

Authorization: MYAPI username:signature 

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

Приложение, которое будет использовать эту услугу, является приложением для iPhone, поэтому я думал, что у нас может быть открытый ключ, встроенный в приложение, с которым мы можем сделать дополнительную подпись, но означает ли это, что нам нужно будет иметь две подписи, один для ключа пользователя и один для ключа приложения?

Любые советы были бы очень благодарны, я бы очень хотел, чтобы это правильно в первый раз.

Answer 1

Я думаю, что самым простым способом сделать это было бы использование аутентификации клиента HTTPS. На этом сайте Apple есть thread.

Редактировать: для обработки авторизации я создавал бы отдельный ресурс (URI) на сервере для каждого пользователя и разрешал бы этому (аутентифицированному) пользователю управлять этим ресурсом.

Редактировать (2014): Apple изменила свое программное обеспечение на форуме за последние шесть лет; нить сейчас находится в https://discussions.apple.com/thread/1643618

Answer 2

Что не так с HTTP Digest Authentication?

Answer 3

Существует лучшее обсуждение этого здесь:

Best Practices for securing a REST API/web service

Answer 4

Ответ прост: это не может быть сделано. Как только вы отправляете какое-либо решение конечному пользователю, он или она могут атаковать сервер, с которым он общается. Самая распространенная версия этой проблемы - обманывать списки привет-очков во флеш-играх. Вы можете сделать это сложнее, введя какое-то шифрование в клиенте и запутывая код ... Но все скомпилированные и обфусканные коды могут быть декомпилированы и без искажений. Это всего лишь вопрос, сколько времени и денег вы готовы потратить, а также для потенциального злоумышленника.

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