Sicurezza in Autenticazione in app a singola pagina

Penso che qui ci siano due punti di partenza.

Servizi Web / servizi REST sullo stesso server della singola app Web.

Non è insolito farlo, né è necessariamente cattivo, e chiaramente anche il modo più semplice. Qualunque sia l'autenticazione scelta (base, digest, modulo, ecc.), L'API e l'app condivideranno le stesse sessioni utente sul server. Il che significa parecchie cose:

• L'API può facilmente rilevare se l'utente è loggato o meno e ottenere le sue autorizzazioni, i ruoli o qualsiasi altra cosa tu abbia bisogno di sapere se l'utente è autorizzato a eseguire una determinata azione.
• Puoi implementare sia l'API che l'app contemporaneamente.
• Il ridimensionamento dell'app è semplice, basta distribuire sia l'API che l'app su un'altra istanza. Anche il bilanciamento del carico è più semplice.
• Monitorare l'app è semplice.
• Sul lato negativo, se vuoi che un'altra app utilizzi questa API, dovrai archiviare questa nuova app sullo stesso server o negoziare tu stesso il login dell'utente (ad esempio, trasmettendo le credenziali al server). Potrebbe essere ancora più complicato se la tua nuova app NON è un'app Web.
• Un altro punto: anche se si tratta di una singola app Web, molto probabilmente caricherete immagini o altre risorse. Se l'utilizzo dell'API è elevato, potrebbe influire sul tempo di caricamento della tua app (che in genere è un "grande" file HTML) e su altre risorse client. Uno dei modi per impedirlo è utilizzare CDN per i tuoi file JavaScript, fogli di stile CSS e immagini.

Penso che questo approccio sia perfettamente adatto per lanciare rapidamente siti web semplici e / o per API che non dovranno essere accessibili da altri servizi. E anche se inizi con questo approccio (sappiamo che tutto è possibile quando si tratta di programmazione, giusto?) Puoi ancora passare a un punto al modello di API / app diviso.

Servizi Web / servizi REST su un server e l'app su un altro.

La best practice oggi per autenticare gli utenti in una SPA collegata a un'API "esterna" o un'API memorizzata su una diversa istanza del server è imitare OAuth nei suoi principi. La chiave è usare ... chiavi, o token ottenuti dal tuo server principale. Il flusso di base dovrebbe essere:

1. Autentica sul server principale (dove è ospitata l'app)
2. Se l'autenticazione ha esito positivo, crea un token e invialo nella risposta HTTP, ad esempio in un cookie.
3. Ogni volta che devi accedere alla tua API, invia il token. Ad esempio, può essere inviato in un'intestazione di richiesta HTTP personalizzata.
4. L'API riceve la richiesta e verifica:
   1. Se la risorsa richiesta richiede un token, altrimenti va bene (esempio: restituzione delle informazioni disponibili agli ospiti, utenti non autenticati)
   2. Se il token è lì, controlla se è ancora accettabile. Decidere come e quando il token scade dipende da te, ci sono vari modi per progettare la strategia di scadenza del token.
   3. Restituisce i dati di risposta (opzionalmente, con un token aggiornato)

Questo approccio ti consente di:

• Dissocia l'API dalle app che stanno per usarlo E dal sistema utente in sé. Certo, devi in qualche modo interpretare il token, ma non hai bisogno di sapere come e dove sono archiviati i dati dell'utente. Se si desidera una nuova app Web o app client / server per accedere a questa API, tutto ciò che serve è un token appropriato.
• Distribuisci separatamente. Ad esempio, l'aggiornamento o la correzione dell'API non provocherà l'arresto del singolo server delle app.
• Monitora l'utilizzo solo dell'API.

Per concludere, applica i principi KISS e YAGNI prima di decidere. E ricorda che puoi sempre passare da un modello all'altro.

Controlla questo post Usando OAuth2 nell'app Web HTML5 . La risposta di @jandersen fornisce una buona spiegazione sull'uso delle credenziali della password del proprietario di risorse nelle applicazioni a singola pagina. In ogni caso, il flusso preferito per queste app dovrebbe essere la sovvenzione implicita . Infatti, la risposta di @jandersen sul post di riferimento riguarda il tweaking delle credenziali della password del proprietario di risorse per agire come qualcosa vicino alla concessione implicita.