Il modo migliore per proteggere il sito Web dell'architettura back-end di javascript front-end / REST?

18

Mi piacerebbe costruire il seguente progetto:

  • back-end dell'API REST pubblico a cui è possibile accedere da qualsiasi client autenticato.
  • front end con file statici in HTML / CSS / Javascript con Backbone.js jQuery chiama al back-end REST

In realtà, ci sono tre parti nella mia architettura: il front-end, che è un client del back-end, il back-end e l'utente che vuole autenticarsi sulla pagina di login front-end.

Qual è il modo migliore per proteggere le tre parti coinvolte in questa architettura?

In effetti, credo che sia impossibile fare un'app sicura sul front end se faccio tutto in javascript, quindi intendo delegare l'autenticazione / autorizzazione a un livello proxy sul front-end del mio server.

Il mio problema è che non so come eseguire questo flusso di lavoro con OAuth:

  • un utente desidera creare un account sul front-end.
  • il front-end delegherà la creazione dell'account al back-end REST.
  • il back-end crea l'account e invia una richiesta in primo piano.
  • quindi l'utente può eseguire chiamate che richiedono l'autorizzazione.

E voglio anche che il mio back end REST sia accessibile a qualsiasi altra applicazione di terze parti con OAuth.

Dovrò utilizzare OAuth a 2 o 3 vie sul back-end REST?

Posso considerare il mio front-end proprio come un'applicazione speciale di terze parti che ha la possibilità di creare un account utente?

Quale protocollo di sicurezza devo usare sul front-end?

    
posta rico 19.12.2011 - 21:06
fonte

1 risposta

2

Bene, dal momento che si specifica che l'API REST può essere accessibile solo da client autenticati, in primo luogo sarà necessario un modulo di sessioni per ricordare lo stato di autenticazione del client. A seconda che sia possibile modificare il codice server dell'API REST, è possibile implementarlo nell'API che fornisce il server stesso.

Ciò potrebbe utilizzare qualsiasi ben noto sistema di autenticazione utente come una combinazione nome utente / password o un certificato (autofirmato).

Tuttavia, proprio come con HTTP, dovrai assicurarti che le password non spostino la linea in testo in chiaro e, una volta autenticata la sessione, la connessione non dovrebbe perdere l'identificatore di sessione che consente il dirottamento. Questo in pratica significa che devi imitare il comportamento simile a SSL o implementare il supporto SSL per il tuo front-end. Un esempio può essere trovato qui: link

Le tue domande relative a OAuth sono una domanda diversa e ti suggerirei di chiederle in una domanda separata se rimane ancora qualcosa che vuoi sapere.

Per quanto riguarda un livello proxy, questa è un'opzione valida solo se l'API non è accessibile al pubblico se non attraverso tale proxy. Questo livello proxy dovrebbe implementare le stesse proprietà simili a SSL, ma questa configurazione offre la funzionalità aggiuntiva di mantenere separati la logica di autenticazione e il provider API. Tuttavia, non lo consiglierei se sei in grado di modificare l'API, perché se una qualsiasi parte del tuo server fornisce accidentalmente l'accesso all'API privata puoi eludere i tuoi requisiti di autenticazione.

    
risposta data 22.04.2012 - 17:34
fonte

Leggi altre domande sui tag