Identità federate di AWS Cognito per più provider di social: meglio unire le identità o tenerle separate?
È possibile unire più identità federate AWS Cognito (ad esempio, accessi a Facebook e Google per la stessa email) in un'unica identità passando entrambi gli accessi nella chiamata Cognito. Ma sapendo che io posso unire le identità non risponde se io dovrei unire le identità.
Quali sono i pro e i contro della fusione delle identità rispetto al tenerle separate? (Memorizziamo i profili utente nel nostro database; non utilizziamo i pool di utenti Cognito. Se non uniamo identità, il nostro database back-end memorizzerebbe la mappatura di ogni ID identità con l'ID utente corretto nel nostro back-end. fine database.)
Ecco il flusso di lavoro corrente dell'app quando lo stesso utente tenta di autenticare utilizzando sia Facebook che Google:
- Sul client (è un'app Web), un nuovo utente fa clic su Accedi e sceglie di accedere utilizzando Facebook.
- Il codice client registra l'utente in Cognito Federated Identities e ottiene un nuovo ID identità federato autorizzato a chiamare le nostre funzioni AWS Lambda.
- Il client chiama la nostra
getOrCreateUserProfile
funzione Lambda che utilizza l'ID identità Cognito come chiave per vedere se quell'identità Cognito è già associata a un utente. - Poiché nessun altro utente con questo ID identità si trova nel nostro database e poiché nessun altro utente ha questo indirizzo email (perché è un utente nuovo di zecca), la nostra funzione Lambda creerà un nuovo profilo utente nel nostro database e restituirà il profilo torna all'utente.
- In un momento successivo, l'utente tenta di accedere (sullo stesso dispositivo o su un altro dispositivo) utilizzando Google.
- Viene creata una nuova identità federata per questa identità Google.
- La nostra
getOrCreateUserProfile
funzione Lambda non riesce a trovare un utente esistente che corrisponda a questo ID identità, ma trova un altro utente con lo stesso indirizzo email.
A questo punto abbiamo tre opzioni:
- A) Restituire un errore all'utente, ad esempio "Accedi utilizzando il tuo account Facebook". Questo è il comportamento attuale che vogliamo cambiare.
- B) Unisci le identità richiedendo all'utente di accedere anche tramite Facebook, quindi passa entrambe le identità a Cognito che le unirà. Vederehttps://stackoverflow.com/a/45045123/126352
- C) Aggiungere una riga di mappatura nel nostro database back-end per mappare la nuova identità al profilo utente esistente dell'utente. Ora questo utente avrà due identità federate: una che utilizza il provider di Facebook, l'altra che utilizza il provider di Google.
Quali sono i pro e i contro dell'opzione (B) rispetto all'opzione (C)? Di seguito è riportato un punto di partenza per questo confronto. Quali pro / contro mi sto perdendo?
Unisci identità
- Pro
- Ricerche più semplici / veloci perché c'è un solo ID identità per utente che deve essere indicizzato sul back-end
- Presumo che questa sia la soluzione più sicura?
- Con
- Il processo di fusione stesso sembra complesso e soggetto a errori. Ad esempio, dopo l'unione, se il nuovo ID "vince" l'unione, dovremo sostituire il vecchio ID con quello nuovo nel profilo utente ... e se qualcosa va storto durante il processo potremmo essere lasciati in uno stato irrecuperabile in cui Cognito conosce solo il nuovo ID (unito) ma il nostro database conosce solo quello vecchio.
- UX più complessa in cui l'utente deve accedere (anche se solo una volta) ad entrambi gli account Facebook e Google nella stessa sessione per collegare tali account.
- Eventuali modifiche successive al collegamento devono passare tramite Cognito API
Mantieni separato
- Pro
- UX più semplice: possiamo collegare gli account social abbinando gli indirizzi email; non c'è bisogno di entrambi gli accessi in una sessione
- Può controllare il collegamento esclusivamente all'interno del nostro database di back-end, il che dovrebbe rendere più semplice la creazione di strumenti di amministrazione che aggiungono / rimuovono / modificano i collegamenti identità-> profilo utente anziché dover chiamare l'API di Cognito per eseguire queste azioni.
- Nessun rischio che Cognito perda la sincronizzazione con il nostro DB back-end. Se il collegamento non riesce, l'utente può semplicemente riprovare.
- Con
- Serve un indice molti: 1 per mappare l'ID identità -> Profilo utente, invece di una singola colonna indicizzata
- È una soluzione meno sicura? In caso affermativo, perché?
- Questo è più costoso in termini di costi AWS? In caso affermativo, perché?
Sono propenso alla soluzione "Keep Separate" perché sembra più semplice da implementare (nessun flusso di lavoro UX extra) e più facile per gli utenti (per lo stesso motivo: nessun nuovo flusso di lavoro UX). È questo un errore?
Risposte
È molto difficile darti una risposta, penso che tu abbia già fornito i principali pro e contro di tutte le possibili soluzioni.
Cercherò di chiarirne solo alcuni, che ritengo fondamentali per scegliere una soluzione e non l'altra.
Prima di tutto, indica che preferirei anche la soluzione tenere separata. Lasciami provare a spiegare perché.
Da un punto di vista dell'esperienza utente, è chiaro che la soluzione Keep Separated è un approccio molto migliore per l'utente. Per unire le identità dei diversi fornitori di social, l'utente deve accedere con loro, in un flusso di lavoro di registrazione dell'applicazione più complesso. Ma questo processo è motivato solo per una decisione tecnica e non fornirà alcun vantaggio effettivo all'utente.
Penso che una soluzione molto migliore e più semplice sia semplicemente includere una mappatura tra ogni identità e l'e-mail associata come proponi nella soluzione Keep separate e lasciare che l'utente acceda all'applicazione con il provider che preferisce, in modo trasparente " merging ", nel codice dell'applicazione, tutti questi meccanismi di accesso. Questo requisito potrebbe essere facilmente raggiunto indipendentemente dal tipo di sistema informativo sottostante utilizzato per memorizzare le informazioni dell'utente.
Per favore, pensa anche a cosa succederà se la tua necessità di includere nella tua applicazione un altro provider di social diverso e un utente già esistente vuole accedere alla tua applicazione con quel nuovo provider: come verranno unite le identità? L'utente deve ripetere nuovamente il processo?
Inoltre, la funzionalità di unione delle identità è qualcosa di molto specifico per Cognito. Se adotti la soluzione di unione, corri il rischio di accoppiare strettamente la tua applicazione con AWS e AWS Cognito. Se devi spostare la tua applicazione su un altro provider di servizi cloud o su una distribuzione in locale, forse non avrai la possibilità di effettuare tale associazione. Ancora una volta, la mappatura tra un qualche tipo di informazioni sull'identità e il modello utente interno adottato nella soluzione Keep Separated sembra un approccio molto migliore e portatile.
Il rischio di non essere sincronizzati con Cognito potrebbe essere un altro grande problema. Quale sarà il meccanismo di recupero?
L'unico vero svantaggio della soluzione di mantenere separata potrebbe essere che probabilmente dovrai sostenere più costi da AWS. Come puoi vedere nella documentazione dei prezzi dei prodotti , AWS ti addebiterà per ogni utente attivo mensile (MAU). Se hai più identità, come con la soluzione Keep separate, è probabile che ci saranno più MAU e potresti sostenere costi più elevati. In ogni caso, questi costi non saranno molto più alti e, tuttavia, credo che i vantaggi che offre la soluzione keep separate compenseranno questo aumento di prezzo minimo.
Infine, non credo che la soluzione di mantenimento della separazione sia un'opzione meno sicura: sebbene sembri che tu stia federando identità per consentire ai tuoi utenti di interagire con i servizi AWS, la stessa politica e assunzione di ruolo verranno applicate indipendentemente dall'identità effettiva fornita dall'utente .
Penso che la soluzione di unione sarà più adatta per scenari in cui si dispone di federazione e si ha bisogno di identificare in modo univoco un utente indipendentemente da come si autentica, ma probabilmente per applicare un qualche tipo di policy (assunzione di ruolo personalizzato, ecc.) Relativa all'uso di risorse AWS basate solo su quelle identità specifiche e, probabilmente, quando non si dispone di un backend dell'applicazione disponibile.
Indipendentemente dalla soluzione finalmente adottata, un fattore chiave di successo sarà quello di mantenere un modello utente e la logica associata il più indipendente possibile dai meccanismi utilizzati per autenticare l'utente: la soluzione keep separate aiuta anche a pensare in quel modo.
Dal punto di vista dell'utente, può sembrare abbastanza confuso e difficile accedere tramite il secondo provider solo per scoprire che non hanno nessuno dei loro contenuti precedenti. Da questo punto di vista penso che la fusione sarebbe il miglior obiettivo finale.
Ora da un punto di vista tecnico ho avuto una svolta e ho scoperto che è piuttosto una seccatura. Sono riuscito a unire le identità quando l'utente accede prima con l'email e poi con i social, ma non il contrario. Immagino che l'unica opzione sia avere un trigger lambda di pre-registrazione che controlla il DB per gli accessi precedenti su quella particolare email e chiede all'utente di accedere anche a quelli per fare l'unione o semplicemente continuare il login su quello esistente. Questo è più facile a dirsi che a farsi se è presente più di un login preesistente.
Sulla questione di chi "vince" l'unione, è sempre quella preesistente. Inoltre, alla fine, non importa poiché tutti gli accessi useranno lo stesso ID federato cognito attraverso le chiamate.