Autenticazione per SPA

Question

Autenticazione per SPA

#1 da (11 voti)

10

Sto sviluppando un'applicazione per la mia azienda con i seguenti parametri e amp; componenti:

Applicazione a singola pagina del front-end (SPA) per la prima parte. Questo è implementato in TypeScript (un dialetto di JavaScript) e stiamo sviluppando il codice internamente.
API REST back-end 1a parte che consente l'accesso a un MongoDB seduto altrove. Questo è implementato in JavaScript e utilizza Express in esecuzione su Node. Stiamo sviluppando il codice internamente. In questo momento tutto ciò che sta facendo è fornire le operazioni CRUD su un'API REST.
Queste applicazioni devono essere disponibili solo per i nostri dipendenti . Tutti i dipendenti hanno computer portatili Windows 10 che sono stati aggiunti a Azure AD della nostra azienda.
Non abbiamo un server ADFS locale. Siamo al 100% cloud.
L'applicazione utilizzerà le risorse di Azure nella sua logica aziendale, come l'API Graph.
L'applicazione utilizzerà anche altre risorse di terze parti, come la nostra azienda Dropbox.
L'autenticazione con "l'applicazione" dovrebbe anche autenticarsi con tutte le altre applicazioni di terze parti (come Dropbox) nel modo più trasparente possibile.
Oggi abbiamo 10 dipendenti. È altamente improbabile che avremo più di 50 dipendenti nei prossimi due anni, quando questa app farà il rev alla versione 2 e assumerò qualcuno per costruirlo.

È giunto il momento di implementare l'autenticazione e l'autorizzazione per la nostra applicazione. L'applicazione deve sia Autenticare che Autorizzare contro Azure AD. Lo scenario ideale è che un utente che ha effettuato l'accesso al computer portatile dell'azienda deve essere autenticato automaticamente dall'autenticità dell'applicazione e che gli utenti su un'altra macchina (pensa al kiosk di aeroporto o hotel) effettueranno l'accesso utilizzando le credenziali di Azure AD. .

La mia domanda riguarda il flusso di concessione OAuth2 da utilizzare in questo scenario.

Ho letto una serie di articoli di Microsoft e OAuth, passati attraverso un certo numero di classi Udemy, ecc., e ho ottenuto consigli contrastanti da queste fonti. Alcuni suggeriscono che le SPA dovrebbero usare una concessione implicita, mentre altri sostengono che se c'è una logica aziendale su un server back-end (e c'è / ci sarà) si dovrebbe usare una concessione di credenziali del client.

Sono uno sviluppatore con molta esperienza, ma non sono un esperto di sicurezza. Nel mio mondo perfetto, esternalizzo la progettazione e l'implementazione del pezzo di autenticazione di questa app a qualcuno che è un esperto di sicurezza, ma il budget è una restrizione importante qui. Semplicemente non è fattibile spendere migliaia di dollari per avere qualcuno che costruisca questo per noi in questa fase.

Tutto ciò detto, dato il design e l'architettura di cui sopra, come dovrebbe essere implementata l'autenticazione? Quale flusso di finanziamento dovrebbe essere usato?

authentication oauth

posta John Dibling 20.12.2016 - 16:57

fonte

1 risposta

Leggi altre domande sui tag authentication oauth

Verifica login e crittografia con PBKDF2 Come posso promuovere buone pratiche relative alle password in un'organizzazione che attualmente non si occupa di questo?

score 11 · Accepted Answer

TL;DR Go with implicit... Check Which OAuth 2.0 flow should I use? for a visualization of the decision process.

Quando si tratta di autenticazione, il diavolo è sui dettagli ... cercherò di non dimenticarlo.

La specifica base OAuth2 ha introdotto quattro tipi di concessione:

concessione implicita
concessione del codice di autorizzazione
le credenziali del client concedono
concessione di credenziali password proprietario risorse (ROPC)

Se escludi ROPC che è stato incluso per fornire un percorso di migrazione senza interruzioni per le applicazioni che hanno utilizzato il nome utente e la password per poter agire per conto dell'utente, ti rimangono tre possibili concessioni.

Tra questi tre, si fa una chiara distinzione tra la concessione di credenziali client (CC) e le altre due. La concessione CC è rivolta alle applicazioni client che desiderano accedere alle risorse per conto proprio, ovvero con l'identità dell'applicazione client stessa.

Ciò implica che per poter utilizzare questa concessione, un'applicazione client deve essere in grado di eseguire l'autenticazione del client per provare che la richiesta proviene dall'applicazione legittima.

Una SPA non può eseguire l'autenticazione del client perché qualsiasi chiave segreta memorizzata nell'applicazione come mezzo per autenticare sarebbe visibile a chiunque volesse guardare attraverso il codice sorgente. La concessione CC viene quindi limitata principalmente alle applicazioni lato server dove mantenere un segreto è più semplice.

Un altro punto importante è che se si desidera che l'applicazione client acceda alle risorse di proprietà di un utente finale e / o esegua azioni per loro conto, la sovvenzione CC non è applicabile.

Sembra che il pool di scelte sia ora metà di quello che abbiamo iniziato e che i rimanenti candidati siano la concessione implicita o del codice di autorizzazione. In generale, se disponi di una SPA il codice che esegue le richieste che richiedono l'autenticazione / l'autorizzazione è sul lato del browser, quindi la scelta più ovvia sarebbe la concessione implicita perché offre la token come parte della risposta dell'endpoint di autorizzazione e non richiede una richiesta aggiuntiva all'endpoint del token che in browser-land potrebbe significare una richiesta CORS che potrebbe o non potrebbe essere fattibile.

Come nota aggiuntiva, se i componenti che hai descritto (Front-end SPA e Back-end API) sono visti come un'unica applicazione che vive sotto lo stesso dominio, senza piani per l'apertura dell'API ad altre applicazioni dovrebbe essere possibile fare affidamento sull'autenticazione basata su cookie solo HTTP tradizionale che verrebbe riavviata da un token ID ricevuto secondo le regole di OpenID Connect. Hai menzionato REST in modo tale che desideri fare una dichiarazione di non responsabilità che l'autenticazione basata su cookie non implichi necessariamente una sessione gestita lato server; tuttavia, l'autenticazione basata su cookie richiederebbe attenzioni CSRF.