Come consentire la registrazione tramite più provider di autenticazione, mentre si condivide lo stesso indirizzo email?

Question

Questa è probabilmente una domanda un po 'tra SO e UX.se, ma per favore nuda con me.

Sto implementando un sistema di registrazione/accesso che consente molteplici modi di autenticazione: registrazioni social utilizzando Facebook, Twitter, Github e una registrazione locale (username + password).

Nel backend sto avendo un modello User e un modello Passport. Un User possono avere più Passports, cioè un User può autenticare attraverso diversi mezzi (es: attraverso signin locale ,. o tramite facebook per esempio)

Per buona misura: il Passports di un particolare User sarà sempre da un altro provider (facebook, twitter, locale). Cioè .: un Facebook-passaporto, un locale-passaporto, ecc

Questo mi sembra un buon modo e mi avrebbe permesso di avere un User account collegato a diversi modi di autenticazione.

ho familiarità con i problemi di sicurezza che questo potrebbe aumentare, così per i passaporti da abbinare/fuse un utente deve essere loggato per entrambi.

Ok al problema. Si consideri il seguente flusso:

1. utenti-segni con un provider, dicono locale, con e-mail user-a@gmail.com
2. utenti-segni fuori (o ha la sua sessione di scaduto).
3. dall'utente a segni utilizzando un altro provider, dicono facebook. È probabile che l'account di Facebook ha un email-record di user-a@gmail.com

Attualmente, ho definito email per essere unico sul User -model. Ciò significherebbe che la registrazione di cui sopra fallirebbe, perché c'è già uno User-account che, tramite il Passaporto locale, ha l'indirizzo email indicato.

Quale potrebbe essere considerato una best practice in una situazione come questa? Spero che ci siano molte implementazioni in giro che devono aver visto questo problema pop-up.

Opzioni:

1. avvertire l'utente l'autenticazione non è possibile e menzionano l'utente che l'attuale indirizzo e-mail è già registrato per mezzo di un altro meccanismo di autenticazione? Questo sarebbe ragionevolmente user-friendly.
2. Nota che un account utente, per mezzo di un provider diverso esiste con lo stesso indirizzo di posta elettronica e di conseguenza unire il nuovo passaporto con l'utente. . Ho appena messo questo in buona misura: questo è un vettore di attacco piuttosto grande e consentirebbe a un utente-b di accedere a un account falsificando l'indirizzo e-mail (attraverso un fornitore di servizi sociali che non esegue la convalida via e-mail)
3. non hai ancora un vincolo di unicità sul <user,email>, ma su <passport, email>. Ciò consentirebbe di creare un nuovo User e lo Passport associato e tutto andrà bene. Ora la stessa persona reale ha probabilmente 2 account utente: 1 per ogni provider di autenticazione. Come fase successiva, è possibile unire gli account utente, accedendo a entrambi e confermando l'unione.

Sono inclinato verso 3, ma 1 è più semplice. Non sono sicuro, cosa ne pensi? Avete già incontrato questo?

Answer 1

Sì, # 3. L'ho implementato io stesso. Il concetto che stai guardando è: Associare più account SSO. La mia struttura utente è la seguente:

name : { 
    first: { type: String}, 
    last: { type: String } 
}, 
emails: [{ type: String, unique: true, 'index': true }], //all known emails as provided by SSO services. we use this to cross ref when the user uses a different SSO to login after initial setup. this avoids account dupes 
sso: [{ 
    provider: { type: String, required: true}, //matches the name of passport strategy name employed 
    userid:  { type: String, required: true } //the specific SSO provider userID that's unique in the provider's realm 
}] 

Così, nella sequenza di autenticazione, si guarda in su e-mail o fornitore + combo userid, se non trovate il provider SSO, di inserirlo. La ragione per o, qualcuno può aggiornare la loro posta elettronica ma l'ID del provider SSO specifico non cambia mai.

Un'altra pratica comune (se ha senso nella tua app) è quella di consentire all'utente di "collegare" account SSO. Ciò ti consente di gestire diversi indirizzi email. Esempio: l'e-mail dell'utente FB è personale ma in LinkedIn elenca come principale quella aziendale. LinkedIn ti dà tristemente solo il primario tramite la sua chiamata OAuth2.