Come proteggere la mia API REST a cui si accede da una sola applicazione? [duplicare]

Devi usare SSL. In caso contrario, indipendentemente dallo schema di sicurezza selezionato, sarà soggetto a sniffare e quindi a bypassare il meccanismo di sicurezza. Ad esempio un utente malintenzionato utilizzando l'avvelenamento DNS farà sì che l'AppA stia parlando con AppB e invii il token all'autore dell'attacco ... da lì l'intero meccanismo di sicurezza è rotto.

SSL fornirà sia l'autenticazione della tua applicazione all'API sia la riservatezza + manomissione dei dati tra l'app e l'API

In SSL puoi configurare l'autenticazione a due vie , il che significa che oltre ad AppA è sicuro che stia parlando con AppB, anche AppB può essere certo che stia parlando con AppA. Questo viene fatto configurando SSL per richiedere anche il certificato client nell'handshake SSL. Questa è la tua migliore opzione. Non rischierei di provare alcun protocollo di sicurezza autodidatta.

Se l'utente è esperto e possiede il dispositivo in cui risiede l'app, puoi dimenticarti di proteggerlo. L'utente può accedere a qualsiasi spazio di archiviazione locale, eseguire l'app in un debugger, utilizzare strumenti di reverse engineering, ecc. Quindi, se lo consideriamo un dato. Devi guardare attentamente ciò che stai cercando di proteggere. Se si presuppone che l'app possa essere utilizzata per servire l'utente e passare da lì, è necessario esaminare ciò che deve essere protetto dall'utente e vedere se è possibile attenuarlo attenuando al contempo questi poteri che consentono comunque all'app di funzionare ma senza il pieno impatto in caso di un utente ostile. Si potrebbe anche voler esaminare il rilevamento lato server di un uso imprevisto dell'API del tipo che l'app non dovrebbe essere in grado di produrre. È possibile utilizzare tale rilevamento in combinazione con la revoca del token. Fondamentalmente dovresti proteggere la tua app e il suo utente dallo spionaggio usando TLS 1.2, disabilitando qualsiasi suite di codici 1.2 e usando token non immaginabili. Non dimenticare di controllare la validità e l'emittente del certificato del server. Dovresti rendere i token revocabili e dovresti cercare di aiutare il tuo utente a impedire che i token vengano cancellati da applicazioni di terze parti dannose. Non dovresti investire in tecnologie simili a DRM che cercano di proteggere i token che in definitiva sono i token degli utenti a cui la tua app può accedere dagli utenti. Un utente persistente troverà sempre un modo per arrivare a quei token se vuole, è la sua macchina. Una progettazione del sistema basata su una minima autorità ben progettata dovrebbe far sì che in realtà non importi se l'utente stesso o la tua app stiano accedendo ai propri servizi. Non cadere nella trappola DRM. Il DRM è al tempo stesso malvagio quando viene eseguito all'estremo e inutile se fatto in altro modo.

Ci sono diversi modi per farlo:

1. Comunicazioni protette : configura un tunnel autenticato tra appA e appB. Questo potrebbe essere fatto con i certificati client su un HTTPS connessione. AppA sa che sta davvero parlando con AppB e AppB lo sa che è davvero AppA a parlarci. In questo modo, non lo fai alterare qualsiasi codice sorgente.

   Se le tue app sono su indirizzi IP statici, potresti persino eseguire il filtraggio degli URL in base all'indirizzo IP di origine. (I.e: solo 1.1.1.1 può accedere al link )

2. Utilizzo di un token . Come hai affermato, un token è più usato a "segreto", cioè: dovrebbe essere molto difficile da indovinare. Solo se appA fa una richiesta e ha il valore segreto corretto, quindi la richiesta è onorato; altrimenti è caduto. È più facile da implementare, ma se qualcuno ricava quel valore, sarà in grado di emettere richieste.

In conclusione, è bene fare "difesa in profondità", se puoi combinarli entrambi, allora avresti un sistema abbastanza sicuro. Quindi, anziché "se un utente malintenzionato ha il valore del token", ti verrebbe da pensare "se l'autore dell'attacco ha lo stesso indirizzo IP, certificato client e il valore del token" - che è meno probabile che accada. A meno che non abbia compromesso i server di AppA.