Micro service REST con autenticazione / autorizzazione utente Javascript

I want the user to log in in the front end, no social authentication or anything.

Non c'è nulla di sociale in OpenID / OAuth2. Fondamentalmente, il vantaggio di OpenID e OAuth2 è che lo sviluppatore faccia affidamento su un sistema esterno per gestire tutta l'autenticazione nel primo caso e l'autorizzazione nel secondo caso.

Per lo sviluppatore, ciò significa che:

• Lo sviluppatore non si assume il rischio di introdurre bug che, in definitiva, consentirebbero a un hacker di accedere al sistema come un utente diverso o manomettere le credenziali dell'utente.

• Il sistema non memorizza alcuna password hash, il che rende il sistema molto meno interessante da hackerare per qualcuno che vuole ottenere le password degli utenti.

• Lo sviluppatore aggiunge facilmente servizi extra.

• Quando un provider inizia a supportare una funzione di sicurezza aggiuntiva, come Autenticazione a due fattori , la ricevi gratuitamente.

Per l'utente, ciò significa che:

• C'è una password in meno da ricordare se l'utente è già registrato sul sito web di terze parti che fornisce il servizio OpenID / OAuth2.

• Oppure, c'è un altro account da creare se l'utente non è registrato sul sito Web di terze parti. Questo potrebbe essere un problema quando l'utente non vuole registrarsi su quel sito Web di terze parti. Ad esempio, se rendi obbligatorio avere un account Facebook per utilizzare il tuo prodotto, non sarò tra i tuoi clienti.

• L'esperienza utente complessiva diventa leggermente più povera, a causa di reindirizzamenti multipli, nonché della perdita di contesto ("Perché sono reindirizzato a Facebook? È un errore?")

L'attuale provider OpenID e OAuth2 potrebbe essere qualsiasi cosa: mentre è vero che molti siti Web sociali ti permettono anche di usare OpenID / OAuth2, non sono soli. I fornitori non sociali includono SalesForce, PayPal e Amazon.

Complete own developed system.

Perché lo faresti?

Come spiegato sopra, il vantaggio di OpenID / OAuth2 è quello di mitigare il rischio spostando codice complesso e dati sensibili dai server. Lascia che esperti di Amazon o Google gestiscano questa cosa. Non mettere a rischio te stesso e i tuoi utenti. A meno che, naturalmente, non sia l'esperto e tu abbia lavorato per l'ultimo decennio sui sistemi di autenticazione, nel qual caso, provaci.

But i was wondering is OAuth2 is the right thing for this architecture. Is the Oauth2 implicit flow good enough for my own developed front end? Or could/should i use the password flow?

OpenID è il flusso della password. Apri il pannello Strumenti dello sviluppatore nel browser e monitora il flusso di rete; vedrai che non c'è magia lì. Per la tua applicazione web, sarà abbastanza semplice impostare OpenID o OAuth2, a seconda della maturità delle librerie di thir-party disponibili per la tua lingua preferita.

Tuttavia, quando si tratta di accedere alle API dal client, si avranno problemi in entrambi i casi: ad un certo momento, l'applicazione web dovrebbe dire all'API che un utente specifico con una chiave e un segreto specifici dovrà accedervi.

Fondamentalmente, a un certo punto, l'app o l'API dovranno generare una coppia chiave-segreta che verrà poi utilizzata dal browser quando eseguirà richieste AJAX su tale API. L'app dovrebbe inoltre comunicare all'API che una determinata chiave è associata a un determinato utente: in questo modo, l'utente sarà in grado di accedere ai suoi dati, ma non ai dati di qualcun altro.

Questo meccanismo è indipendente dalla scelta tra OpenID / OAuth2 e un sistema fatto in casa. Lo scopo dell'autenticazione è l'applicazione web; Le API non autenticano gli utenti ; autenticano altre applicazioni, si tratterebbe della tua app web o di una terza parte.

Il riposo riguarda l'utilizzo dei meccanismi già esistenti di Internet. Il Web offre già diversi meccanismi di autenticazione http.BASIC, Digest, ecc. Prendi in considerazione l'utilizzo dell'autenticazione di base su ssl.