Tan pronto como lance la aplicación, es posible que tenga ingeniería inversa. Esto significa que no hay nada que pueda hacer para estar 100% protegido si la misma aplicación (los mismos binarios, la misma configuración) se distribuye a todos sus usuarios.
Si puede personalizar la aplicación para cada usuario, entonces tiene la posibilidad de no prohibir que alguna otra aplicación use su API, pero al menos limite esta aplicación por el número de solicitudes que puede hacer a la API.
Imagine el siguiente esquema:
- El cliente se conecta y envía su identificador único (un identificador por usuario).
- El servidor responde enviando un desafío encriptado con una clave pública. Esta clave pública está asociada con el identificador único enviado previamente.
- El cliente resuelve el desafío descifrando los datos utilizando una clave privada y envía el secreto descifrado de vuelta al servidor.
- El servidor verifica que el secreto enviado corresponde al generado originalmente.
El desarrollador que pirateará su aplicación y obtendrá con éxito la clave privada podrá utilizar su API desde su propia aplicación, pero será el identificador como él mismo para su servidor.
Si el mismo usuario puede hacer 10 000 solicitudes a su API por día y, en promedio, un usuario activo realiza 2 000 solicitudes por día, significa que este desarrollador podría usar su aplicación él mismo y tal vez dársela a sus amigos, pero no podría, por ejemplo, venderlo a miles de personas, solo porque funcionará solo durante unos minutos por la mañana.
Si bien esto ayuda, tampoco es 100% a prueba. ¿Qué sucede si el hacker encuentra una manera de extraer la clave privada de su aplicación cuando su propia aplicación está instalada en el dispositivo?
Nota al margen que no responde a su pregunta, pero que podría ser útil: no piense en una API como herramienta para su producto principal (aplicación móvil). Piense en ello como un producto de primera clase en sí mismo, un producto que puede pagarse. Amazon y Google usan el mismo modelo durante años, Microsoft comienza a usarlo activamente con Azure, etc.
Tan pronto como considere que la API no es una herramienta secundaria reducida a la esclavitud de sus nuevas y brillantes aplicaciones móviles, sino el producto real, al mismo nivel que cualquier aplicación que el usuario realmente vea, comienza a pensar menos sobre cómo proteger la API contra el uso por otras aplicaciones, y más sobre la monetización de la API en sí. Dicha API puede ser utilizada por sus aplicaciones que son sus clientes, o cualquier otra aplicación, desarrollada libremente por cualquier persona. Esto tiene varios beneficios:
Hacer una API para que solo sea utilizado por sus aplicaciones es difícil y costoso. Este tiempo y dinero pueden usarse para algo más útil.
Abrir su API al público puede tener un gran beneficio tanto para usted como para el mundo. Imagina que eres un gran arquitecto y un gran desarrollador, por lo que has creado una API asombrosamente genial, pero tus habilidades de diseñador visual apestan y realmente no entiendes nada sobre el diseño de interacción, etc. Si ocultas tu API, el único Lo que la gente sabrá es que has creado una aplicación móvil que es inutilizable y fea. Si su API es pública, otros desarrolladores se sentirán atraídos por su calidad y escribirán excelentes aplicaciones para él, lo que le brindará mucho dinero.
Nunca imaginas cómo otras personas pueden usar tus API. Esto es lo que sucedió con Kinect. Originalmente, Microsoft creó Kinect para juegos. Cuando Microsoft abrió la API al público, nunca imaginaron que sería utilizada unos años más tarde por aplicaciones científicas, sector de la salud, etc. Es similar para las API web: más desarrolladores la están utilizando, más generalizadas serían las ideas.
