Non appena si rilascia l'applicazione, potrebbe essere decodificato. Ciò significa che non c'è nulla che tu possa fare per essere protetto al 100% se la stessa applicazione (stessi binari, stesse impostazioni) è distribuita a tutti i tuoi utenti.
Se puoi personalizzare l'applicazione per ogni utente, allora potresti non proibire ad altre applicazioni di utilizzare la tua API, ma almeno limitare questa applicazione al numero di richieste che può fare all'API.
Immagina il seguente schema:
- Client si connette e invia il suo identificativo univoco (un identificativo per utente).
- Risposta del server inviando una sfida crittografata con una chiave pubblica. Questa chiave pubblica è associata all'identificatore univoco precedentemente inviato.
- Il client risolve la sfida decodificando i dati utilizzando una chiave privata e invia il segreto decrittografato in chiaro al server.
- Server verifica che il segreto inviato corrisponda a quello originariamente generato.
Lo sviluppatore che hackerà la tua applicazione e otterrà la chiave privata con successo potrà utilizzare la tua API dalla sua applicazione, ma sarà identificato come se stesso per il tuo server.
Se lo stesso utente può fare 10.000 richieste alla tua API al giorno e, in media, un utente attivo fa 2 000 richieste al giorno, significa che questo sviluppatore sarebbe in grado di utilizzare la sua applicazione da solo e magari darlo alla sua amici, ma non sarebbe in grado, diciamo, di venderlo a migliaia di persone, solo perché funzionerà solo per pochi minuti al mattino.
Anche se questo aiuta, non è nemmeno una prova al 100%. Cosa succede se l'hacker trova un modo per estrarre la chiave privata dalla tua app quando la sua app è installata sul dispositivo?
Nota a margine che non risponde alla tua domanda, ma potrebbe comunque essere utile: non pensare a un'API come strumento per il tuo prodotto principale (applicazione mobile ). Consideralo come un prodotto di prima classe, un prodotto che può essere pagato. Lo stesso modello viene usato per anni da Amazon e Google, inizia ad essere utilizzato attivamente da Microsoft con Azure, ecc.
Non appena consideri l'API non come uno strumento secondario ridotto alla schiavitù per le tue nuove e splendide app mobili, ma il prodotto reale, allo stesso livello di qualsiasi applicazione che l'utente vede effettivamente, inizi a pensare meno a come proteggere l'API contro l'utilizzo da parte di altre app e altro sulla monetizzazione dell'API . Tale API può essere utilizzata dalle tue app che sono i suoi clienti o qualsiasi altra app, liberamente sviluppata da chiunque. Questo ha diversi vantaggi:
-
Creare un'API in modo che possa essere utilizzato solo dalle tue applicazioni è difficile e costoso. Questa volta e denaro possono essere utilizzati per qualcosa di più utile.
-
L'apertura della tua API al pubblico può avere un grande vantaggio per te e per il mondo. Immagina di essere un grande architetto e un grande sviluppatore, quindi hai creato un'API sorprendentemente grande, ma le tue abilità di visual designer non sono ottimali e non capisci nulla dell'interaction design, ecc. Se nascondi la tua API, l'unica la gente saprà che hai creato un'applicazione mobile che è inutilizzabile e brutta. Se la tua API è pubblica, altri sviluppatori saranno attratti dalla sua qualità e scriveranno ottime applicazioni per questo, portandoti un sacco di soldi.
-
Non immagini mai come altre persone possano usare le tue API. Questo è quello che è successo con Kinect. Originariamente, Microsoft ha creato Kinect per i giochi. Quando Microsoft ha aperto l'API al pubblico, non hanno mai immaginato che sarebbe stata utilizzata qualche anno dopo da applicazioni scientifiche, settore sanitario, ecc. È simile per le API Web: più sviluppatori lo usano, più diffusa sarebbe l'idea.