Как только вы выпустите приложение, оно может быть переработано. Это означает, что вы ничего не можете сделать, чтобы быть на 100% защищенными, если одно и то же приложение (одни и те же двоичные файлы, одинаковые настройки) распространяется среди всех ваших пользователей.
Если вы можете настроить приложение для каждого пользователя, то у вас есть возможность, возможно, не запрещать другим API использовать ваш API, но, по крайней мере, ограничить это приложение количеством запросов, которые оно может выполнить к API.
Представьте себе следующую схему:
- Клиент подключается и отправляет свой уникальный идентификатор (один идентификатор на пользователя).
- Сервер отвечает отправкой запроса в зашифрованном виде с открытым ключом. Этот открытый ключ связан с ранее отправленным уникальным идентификатором.
- Клиент решает проблему путем дешифрования данных с помощью закрытого ключа и отправляет расшифрованный секрет в открытом виде обратно на сервер.
- Сервер проверяет, что представленный секрет соответствует первоначально сгенерированному.
Разработчик, который взломает ваше приложение и успешно получит закрытый ключ, сможет использовать ваш API из своего собственного приложения, но он будет идентифицировать себя для вашего сервера.
Если один и тот же пользователь может делать 10 000 запросов к вашему API в день, и в среднем активный пользователь делает 2000 запросов в день, это означает, что этот разработчик сможет использовать свое приложение сам и, возможно, передать его своим друзьям, но скажем, он не сможет продать его тысячам людей только потому, что утром он будет работать всего несколько минут.
Хотя это помогает, но это не 100% доказательство. Что если хакер найдет способ извлечь закрытый ключ из вашего приложения, когда его собственное приложение установлено на устройстве?
Дополнительное примечание, которое не отвечает на ваш вопрос, но все же может быть полезно: не думайте об API как инструменте для вашего основного продукта (мобильного приложения). Думайте об этом как о первоклассном продукте , продукте, который может быть оплачен. Одна и та же модель годами используется Amazon и Google, она начинает активно использоваться Microsoft с Azure и т. Д.
Как только вы рассматриваете API не как вторичный инструмент, превращенный в рабство для ваших новых мобильных приложений, а как реальный продукт на том же уровне, что и любое приложение, которое фактически видит пользователь, вы начинаете меньше думать о том, как защитить API от использование другими приложениями, и больше о монетизации самого API . Такой API может использоваться вашими приложениями, которые являются его клиентами, или любыми другими приложениями, свободно разработанными кем-либо. Это имеет несколько преимуществ:
Создание API-интерфейса таким образом, чтобы оно использовалось только вашими приложениями, является сложным и дорогостоящим. Это время и деньги могут быть использованы для чего-то более полезного.
Открытие вашего API для публики может принести большую пользу как вам, так и миру. Представьте, что вы великий архитектор и отличный разработчик, поэтому вы создали удивительно прекрасный API, но ваши навыки визуального дизайнера ужасны, и вы действительно ничего не понимаете в области интерактивного дизайна и т. Д. Если вы скрываете свой API, единственным люди будут знать, что вы создали мобильное приложение, которое непригодно и неприглядно. Если ваш API общедоступен, другие разработчики будут привлечены его качеством и будут писать отличные приложения для него, принося вам много денег.
Вы никогда не представляете, как другие люди могут использовать ваши API. Это то, что случилось с Kinect. Первоначально Microsoft создала Kinect для игр. Когда Microsoft открыла API для широкой публики, они даже не предполагали, что через несколько лет его будут использовать научные приложения, сектор здравоохранения и т. Д. Он похож на веб-API: чем больше разработчиков его использует, тем шире распространяются идеи.
