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

Question

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

<Ол>

Это должно быть безопасно.

Пользователи не должны иметь возможность подделывать запросы.

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

Authorization: MYAPI username:signature

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Что не так с дайджест-аутентификацией HTTP ?

Answer 4

Здесь лучше обсудить это:

Рекомендации по защите REST API / веб-службы