Авторизация запросов REST

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

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

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

Authorization: MYAPI username:signature

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

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

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

13
authentication authorization http-headers rest rest-security

4 ответов

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

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

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

1

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

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

8
2
1