11

Ho 2 server sul posto, uno è responsabile per l'applicazione front-end e l'autenticazione dell'utente. Questo server sta eseguendo il rendering di un'applicazione a pagina singola codificata in javascript. Questa app javascript esegue il rendering dei dati da un secondo server tramite un'API REST ospitata su questo secondo server.Come proteggere un'API REST tra un'app singola e un server?

Vorrei proteggere questo secondo server. Mi piacerebbe che solo l'applicazione di frontend fosse in grado di chiamare il server di backend.

Al momento chiunque può chiamare il resto api dal browser per interrogare i dati.

Grazie per il vostro aiuto.

+0

perché devono essere su 2 server diversi? stai usando lingue diverse? – mpm

+0

No, la stessa lingua è utilizzata su entrambi i server. Ho messo il resto api su un server e il frontend su un altro server per motivi di scalabilità e separazioni di problemi. – Michael

risposta

11

Tutto ciò che l'app javascript può fare nel client del browser può essere visto da qualcun altro per accedere al server API REST back-end esterno all'app.

In realtà, il fatto che l'app client sia implementata in JavaScript è insignificante - qualsiasi applicazione eseguita su una macchina fuori dal tuo controllo non può essere completamente affidabile. È un po 'più difficile decodificare il codice nativo exectuable rispetto a ViewSource su un'app javascript, ma non impossibile. Mai fare affidamento sulla sicurezza dall'oscurità.

La soluzione migliore è quella di avere l'applicazione del browser richiede all'utente finale di accedere e ottenere un token di autenticazione da un provider di identità di fiducia, e presente che auth token ogni richiesta l'applicazione browser alla API REST. L'API REST può quindi convalidare il token di autenticazione per verificare se proviene da un provider attendibile e se l'utente indicato all'interno del token è autorizzato a utilizzare l'API REST.

Questo collega l'autorizzazione delle chiamate API REST all'utente anziché all'app e utilizza segreti (credenziali utente) che non risiedono nell'app browser per essere visualizzati da tutto il mondo.

Con questa soluzione, è possibile limitare l'accesso all'API REST in base al quale l'utente sta effettuando la chiamata. Puoi ancora filtrare l'accesso in base all'app che sta effettuando la richiesta, ma questo dovrebbe essere un punto secondario, non il fattore di sicurezza principale, perché è più facile copiare la descrizione dell'applicazione rispetto alle credenziali dell'utente.

Un'altra opzione potrebbe essere quella di fare in modo che il server Web funga da proxy per il servizio API REST in modo che l'app browser debba passare attraverso il server Web per ottenere i dati dall'API REST. Questo potrebbe essere fattibile se l'app del browser mantiene lo stato della sessione che il server Web può verificare per determinare che la richiesta provenga dall'app bona-fide e non da qualcun altro. Anche se ciò potrebbe consentire di mantenere la tua API REST fuori dalla rete pubblica, in realtà non cambia il tuo problema di autorizzazione - lo hai appena spostato sul server web dove potresti avere più contesto di sessione per distinguere una richiesta in-app da una richiesta interlocutoria. Tenuo nel migliore dei casi, non consigliato a meno che tu non sia davvero sicuro dello stato della sessione dell'app.

Indipendentemente da ciò che la soluzione che si sceglie, resta il fatto che se la vostra API REST è accessibile da un'applicazione client-side (browser o altro), si tratta di un'API REST pubblica e deve essere trattato (e fortificata) in quanto tale. Non esiste una API Web privata a cui è possibile accedere da un computer client.

+0

grazie per la tua risposta. Mi piace la tua idea di avere un token di autenticazione attendibile ricevuto da un fornitore di fiducia. Quello che stai spiegando è fondamentalmente il meccanismo oAuth? Immaginiamo che un utente stia autenticando la mia app con Google o con qualsiasi altro fornitore fidato.In cambio ottengono un tocken in cambio e posso usare questo tocken per firmare una delle mie chiamate API. – Michael

+0

Sì, OAuth è un tale sistema di token. Quindi è SAML. Sì, puoi utilizzare i token emessi da Google e altri per autenticare il chiamante della tua API. L'API dovrà convalidare il token (verificare la firma con certificati noti o chiamare il fornitore). Google fornisce API per fare questo con il loro sistema in modo da non dover entrare nei dettagli sporchi del protocollo filo e dei formati di pacchetto. – dthorpe

+1

Si noti che Google e altri provider di identità forniscono solo l'autenticazione dell'utente. La tua API può fidarsi che l'identità del chiamante sia autentica, ma devi comunque decidere autonomamente dell'autorizzazione. Esistono sistemi di token server (STS) sicuri completi che forniscono informazioni su identità e ruolo/diritto/permesso. Google, FB, ecc. Forniscono solo identità. – dthorpe

Problemi correlati