Assim que você libera o aplicativo, ele pode sofrer engenharia reversa. Isso significa que não há nada que você possa fazer para estar 100% protegido se o mesmo aplicativo (mesmos binários, mesmas configurações) for distribuído a todos os seus usuários.
Se você pode personalizar o aplicativo para cada usuário, é possível que talvez não proíba outro aplicativo de usar sua API, mas pelo menos limite esse aplicativo pelo número de solicitações que ele pode fazer à API.
Imagine o seguinte esquema:
- O cliente conecta e envia seu identificador exclusivo (um identificador por usuário).
- O servidor responde enviando um desafio criptografado com uma chave pública. Essa chave pública está associada ao identificador exclusivo enviado anteriormente.
- O cliente resolve o desafio descriptografando os dados usando uma chave privada e envia o segredo descriptografado de volta ao servidor.
- O servidor verifica se o segredo enviado corresponde ao originalmente gerado.
O desenvolvedor que invadir seu aplicativo e obter a chave privada com êxito poderá usar sua API a partir de seu próprio aplicativo, mas ele será o próprio identificador de seu servidor.
Se o mesmo usuário puder fazer 10.000 solicitações para sua API por dia e, em média, um usuário ativo fizer 2.000 solicitações por dia, isso significa que esse desenvolvedor poderá usar o aplicativo por conta própria e talvez dar a seus amigos, mas ele não seria capaz de, por exemplo, vendê-lo para milhares de pessoas, apenas porque funcionaria apenas por alguns minutos pela manhã.
Embora isso ajude, também não é 100% à prova. E se o hacker encontrar uma maneira de extrair a chave privada do seu aplicativo quando ele estiver instalado no dispositivo?
Nota lateral que não responde à sua pergunta, mas ainda pode ser útil: não pense em uma API como uma ferramenta para seu produto principal (aplicativo móvel). Pense nisso como um produto de primeira classe , um produto que pode ser pago. O mesmo modelo é usado há anos pela Amazon e Google, passa a ser usado ativamente pela Microsoft com o Azure etc.
Assim que você considerar a API não como uma ferramenta secundária reduzida à escravidão para seus novos aplicativos móveis brilhantes, mas o produto real, no mesmo nível de qualquer aplicativo que o usuário realmente visualizar, você começará a pensar menos em como proteger a API. o uso por outros aplicativos e mais sobre a monetização da própria API . Essa API pode ser usada por seus aplicativos, que são seus clientes ou qualquer outro aplicativo, desenvolvido livremente por qualquer pessoa. Isso tem vários benefícios:
Fazer uma API para que ela fosse usada apenas por seus aplicativos é difícil e caro. Esse tempo e dinheiro podem ser usados para algo mais útil.
Abrir sua API ao público pode trazer um grande benefício para você e o mundo. Imagine que você é um ótimo arquiteto e um ótimo desenvolvedor, por isso criou uma API surpreendentemente ótima, mas suas habilidades de designer visual são péssimas e você realmente não entende nada sobre design de interação etc. Se você oculta sua API, a única o que as pessoas saberão é que você criou um aplicativo móvel que não pode ser usado e é feio. Se sua API for pública, outros desenvolvedores serão atraídos por sua qualidade e criarão ótimos aplicativos para ela, trazendo muito dinheiro.
Você nunca imagina como outras pessoas podem usar suas APIs. Foi o que aconteceu com o Kinect. Originalmente, a Microsoft criou o Kinect para jogos. Quando a Microsoft abriu a API ao público, eles nunca imaginaram que ela seria usada alguns anos depois por aplicativos científicos, setor de saúde etc. É semelhante para APIs da Web: mais desenvolvedores estão usando, mais difundidas serão as idéias.