Dès que vous relâchez l'application, elle peut être rétroconçue. Cela signifie que vous ne pouvez rien faire pour être protégé à 100% si la même application (mêmes binaires, mêmes paramètres) est distribuée à tous vos utilisateurs.
Si vous pouvez personnaliser l'application pour chaque utilisateur, vous avez peut-être la possibilité d'interdire à une autre application d'utiliser votre API, mais au moins de limiter cette application par le nombre de demandes qu'elle peut faire à l'API.
Imaginez le schéma suivant:
- Le client se connecte et envoie son identifiant unique (un identifiant par utilisateur).
- Le serveur répond en envoyant un défi chiffré avec une clé publique. Cette clé publique est associée à l'identifiant unique envoyé précédemment.
- Le client résout le défi en déchiffrant les données à l'aide d'une clé privée et envoie le secret déchiffré en clair au serveur.
- Le serveur vérifie que le secret soumis correspond à celui généré à l'origine.
Le développeur qui piratera votre application et obtiendra avec succès la clé privée pourra utiliser votre API à partir de sa propre application, mais il sera identifiant comme lui-même pour votre serveur.
Si le même utilisateur peut faire 10 000 requêtes par jour à votre API et en moyenne, un utilisateur actif fait 2 000 requêtes par jour, cela signifie que ce développeur pourra utiliser lui-même son application et peut-être la donner à ses amis, mais il ne pourrait pas, par exemple, le vendre à des milliers de personnes, simplement parce que cela ne fonctionnera que quelques minutes le matin.
Bien que cela aide, ce n'est pas non plus une preuve à 100%. Que faire si le pirate trouve un moyen d'extraire la clé privée de votre application lorsque sa propre application est installée sur l'appareil?
Note complémentaire qui ne répond pas à votre question, mais qui pourrait quand même être utile: ne pensez pas à une API comme outil pour votre produit principal (application mobile). Considérez-le comme un produit de première classe lui-même, un produit qui peut être payé. Le même modèle est utilisé depuis des années par Amazon et Google, il commence à être activement utilisé par Microsoft avec Azure, etc.
Dès que vous considérez l'API non pas comme un outil secondaire réduit à l'esclavage pour vos nouvelles applications mobiles brillantes, mais le produit réel, au même niveau que n'importe quelle application que l'utilisateur voit réellement, vous commencez à penser moins à la façon de protéger l'API contre l'utilisation par d'autres applications, et plus sur la monétisation de l'API elle-même. Cette API peut être utilisée par vos applications qui sont ses clients, ou toute autre application, librement développée par n'importe qui. Cela présente plusieurs avantages:
Faire une API pour qu'elle ne soit utilisée que par vos applications est difficile et coûteux. Ce temps et cet argent peuvent être utilisés pour quelque chose de plus utile.
L'ouverture de votre API au public peut avoir un grand avantage pour vous et pour le monde. Imaginez que vous êtes un grand architecte et un grand développeur, vous avez donc créé une API étonnamment géniale, mais vos compétences de concepteur visuel sont nulles et vous ne comprenez vraiment rien à la conception d'interaction, etc. Si vous cachez votre API, la seule Ce que les gens savent, c'est que vous avez créé une application mobile inutilisable et moche. Si votre API est publique, d'autres développeurs seront attirés par sa qualité et y rédigeront de superbes applications, vous rapportant beaucoup d'argent.
Vous n'imaginez jamais comment d'autres personnes peuvent utiliser vos API. C'est ce qui s'est produit avec Kinect. À l'origine, Microsoft a créé Kinect pour les jeux. Lorsque Microsoft a ouvert l'API au public, ils n'ont jamais imaginé qu'elle serait utilisée quelques années plus tard par les applications scientifiques, le secteur de la santé, etc. Il en va de même pour les API Web: plus de développeurs l'utilisent, plus les idées seraient répandues.
