Autenticazione basata su OpenID in Angular.js (con il backend del pallone)

Question

Come si implementa l'autenticazione basata su OpenID in Angular.js (con l'app Web back-end di Flask)?

Sembra che il codice Angular.js deve incorporare una logica come nell'esempio found here.

Tuttavia, il lato Flask dovrebbe anche avere un meccanismo di verifica OpenID.
Esiste un modo "consigliato" per scrivere la logica sia per il backend che per il frontend?
Esiste un esempio github o qualche altra risorsa correlata per i principianti?

Answer 1

Purtroppo non ho un'applicazione di esempio da condividere, ma qui c'è una descrizione di alto livello che spero sia utile.

Dimentichiamo per un momento che si dispone di un app AngularJS e rivedere come funziona lo scambio di autenticazione OpenID: entra

1. utente URL OpenID in un form di login e presenta al server
2. Il server riceve il OpenID URL e risponde con un reindirizzamento al provider OpenID. Il reindirizzamento include alcuni argomenti, incluso un URL di richiamata.
3. Il provider OpenID richiede all'utente di immettere le credenziali di accesso e quindi di consentire la condivisione del proprio nome con l'applicazione server.
4. Il provider OpenID risponde con un reindirizzamento all'applicazione, all'URL fornito come richiamata nel passaggio 2 e rende disponibili informazioni sull'utente, quali ID, e-mail, nome utente, ecc.
5. Il server ora dispone di informazioni utente e può individuare l'utente nel proprio database utente tramite l'ID univoco, l'indirizzo di posta elettronica o qualche altro elemento di identificazione. A questo punto è possibile creare un nuovo account se l'utente non è noto all'applicazione.
6. Ora che l'utente è noto, il server può scrivere un cookie che registra chi è, ma nota che questa è un'identità diversa da quella del passaggio 5. Le informazioni di identità restituite dal provider OpenID erano utili per individuare l'utente nel proprio database, quindi ora è possibile registrare l'identità dell'utente nel contesto dell'applicazione. Questo potrebbe essere un ID utente del database, l'indirizzo e-mail o il nome utente (se sono univoci) o un token, che può essere un hash di alcune delle informazioni che hai sull'utente.
7. Con il cookie scritto ogni nuova richiesta inviata al server viene fornita con i dati che identificano l'utente autenticato.

Quindi vediamo cosa succede quando aggiungete AngularJS al mix. Nota che ci sono molti modi per farlo, quello che descrivo qui sotto è una possibilità.

Se l'applicazione Angolare invia una richiesta al server che richiede l'autenticazione, il server deve restituire un codice di errore 401. L'app Angolare può apparire come un modulo di login quando ottiene un 401, ad esempio.

Ma l'autenticazione di autenticazione OpenID non può essere eseguita tutto nel contesto di una ricca applicazione JS perché richiede reindirizzamenti del browser.L'applicazione lato server dovrà sostenere almeno tre percorsi:

• un URL principale che serve l'applicazione angolare
• un URL che avvia l'autenticazione OpenID
• un URL che viene inviato come richiamata al provider OpenID

Così l'utente si connette all'URL di root e ottiene l'app AngularJS, che inizia in uno stato non autenticato. Ad un certo punto l'app Angular richiederà all'utente di accedere, utilizzando un modulo che ha un campo di testo OpenID e un pulsante di invio. Questi campi modulo devono far parte di un normale modulo HTML che invia al server, non elementi angolari lato client collegati a un controller. L'attributo "azione" del modulo deve puntare alla rotta di accesso OpenID del server.

Quando l'utente fa clic sul pulsante di accesso, il server si risveglia e riceve la richiesta di avviare l'autenticazione OpenID. A questo punto i passaggi 1-5 sopra funzionano senza modifiche.

Alla fine del passaggio 5 il server ha individuato l'utente nel database dell'applicazione. Ciò che il server può fare ora è rispondere con un reindirizzamento all'URL di root, per riavviare l'app Angular. Se l'app deve essere riavviata in uno stato che non è lo stato iniziale, lo stato da ripristinare può essere salvato nella memoria lato client (un cookie, ad esempio) prima di avviare il processo di autenticazione OpenID.

Ma questo non è sufficiente, il server deve anche passare ad Angular alcune informazioni sull'utente che ha effettuato l'accesso. Un modo per farlo è collegare l'ID o il token univoco dell'utente nella stringa di query dell'URL di reindirizzamento, che l'app Angolare può accedere. Questo sarebbe lo stesso pezzo di ID inserito in un cookie nel passaggio 6 sopra.

Ora l'app Angolare viene riavviata, può ripristinarne lo stato se necessario e dispone di un ID o di un token che identifica l'utente che ha effettuato l'accesso. Quando l'app deve inviare una richiesta Ajax al server, invia questo ID o token insieme alla richiesta. Il server può verificarlo e restituire 401 se trovato non è valido o se ha una data di scadenza e risulta essere scaduto.

Se l'identificazione inviata con la richiesta viene verificata, è possibile eseguire la richiesta e inviare una risposta all'app Angular.

Una funzione di disconnessione può essere implementata sul lato client semplicemente eliminando l'ID utente/token, in modo che le future richieste al server vengano inviate nuovamente senza autenticazione.

Molto importante: tutti gli scambi tra l'app Angolare e il server Flask che includono le informazioni dell'utente devono essere eseguiti tramite HTTP protetto. In caso contrario, i tuoi ID o token viaggeranno in testo normale.