Как защитить rest api? Представим абстрактную ситуацию: Есть веб сервис, у которого есть rest api. Если для этого сервиса клиентские приложения под win, linux, osx, ios, android. Api веб сервиса позволяет клиентским приложениям делать с пользователями все, от регистрации и авторизации до вывода средств. Все взаимодействия через https. Вопрос 1: как защитить api от автоматизированной регистрации/брута авторизации/подобных неприятностей? Документация api третьим лицам по умолчанию не известна, однако ничего не мешает им(третьим лицам) расковырять клиентское приложение и узнать, как с данным api взаимодействовать. Вопрос 2: Есть ли какой-то хитрый алгоритм/способ/магия, с помощью которых можно гарантировано проверять подлинность клиентских приложений в тот момент, когда они начинают взаимодействовать с rest api. Иными словами гарантировать то, что приложение, взаимодействующее с api именно то приложение, которое выпущено производителем самого api, а не написанный доброжелателем брутер/регистратор/еще какая гадость.
Использование капчи или рекапчи для предотвращения автоматизированных регистраций.Введение ограничений на количество попыток авторизации (например, блокировка аккаунта после определенного числа неудачных попыток).Использование токенов доступа (access tokens) для авторизации и аутентификации клиентских приложений.
Ответ на второй вопрос:
Использование токенов доступа с обязательной авторизацией разработчика приложения и выдачей уникального ключа для каждого приложения.Подпись запросов с использованием общего секретного ключа между сервером и клиентским приложением.Использование SSL-сертификатов для подтверждения подлинности сервера.
Ответ на первый вопрос:
Использование капчи или рекапчи для предотвращения автоматизированных регистраций.Введение ограничений на количество попыток авторизации (например, блокировка аккаунта после определенного числа неудачных попыток).Использование токенов доступа (access tokens) для авторизации и аутентификации клиентских приложений.Ответ на второй вопрос:
Использование токенов доступа с обязательной авторизацией разработчика приложения и выдачей уникального ключа для каждого приложения.Подпись запросов с использованием общего секретного ключа между сервером и клиентским приложением.Использование SSL-сертификатов для подтверждения подлинности сервера.