AWS Cognito Federated Identities untuk beberapa penyedia sosial: lebih baik menggabungkan identitas atau memisahkannya?
Beberapa Identitas Federasi Kognito AWS (misalnya, login Facebook dan Google untuk email yang sama) dapat digabungkan menjadi satu identitas dengan meneruskan kedua login tersebut dalam panggilan Cognito. Tetapi mengetahui bahwa saya dapat menggabungkan identitas tidak menjawab apakah saya harus menggabungkan identitas.
Apa pro dan kontra dari menggabungkan identitas vs. memisahkannya? (Kami menyimpan profil pengguna di database kami sendiri; kami tidak menggunakan Cognito User Pools. Jika kami tidak menggabungkan identitas, maka database back-end kami akan menyimpan pemetaan setiap ID identitas ke ID pengguna yang benar di bagian belakang kami. database akhir.)
Berikut adalah alur kerja aplikasi saat ini ketika pengguna yang sama mencoba melakukan autentikasi menggunakan Facebook dan Google:
- Di klien (ini adalah aplikasi web), pengguna baru mengklik Login dan memilih untuk login menggunakan Facebook.
- Kode klien memasukkan pengguna ke dalam Cognito Federated Identities dan mendapatkan ID identitas federasi baru yang diberi otorisasi untuk memanggil fungsi AWS Lambda kami.
- Klien memanggil
getOrCreateUserProfilefungsi Lambda kami yang menggunakan Cognito Identity ID sebagai kunci untuk melihat apakah identitas Cognito tersebut telah dikaitkan dengan pengguna. - Karena tidak ada pengguna lain dengan ID identitas ini yang ditemukan di database kami, dan karena tidak ada pengguna lain yang memiliki alamat email ini (karena ini adalah pengguna baru), maka fungsi Lambda kami akan membuat profil pengguna baru di database kami dan mengembalikan profil tersebut kembali ke pengguna.
- Suatu saat nanti, pengguna mencoba masuk (di perangkat yang sama atau di perangkat lain) menggunakan Google.
- Federasi Identitas baru dibuat untuk identitas Google ini.
getOrCreateUserProfileFungsi Lambda kami tidak dapat menemukan pengguna yang cocok dengan ID Identitas ini, tetapi menemukan pengguna lain dengan alamat email yang sama.
Saat ini kami memiliki tiga opsi:
- A) Kembalikan kesalahan ke pengguna, misalnya "Harap masuk menggunakan akun Facebook Anda". Inilah perilaku saat ini yang ingin kami ubah.
- B) Gabungkan identitas dengan meminta pengguna untuk masuk menggunakan Facebook juga, lalu berikan kedua identitas tersebut ke Cognito yang akan menggabungkannya. Lihathttps://stackoverflow.com/a/45045123/126352
- C) Tambahkan baris pemetaan di database back-end kami untuk memetakan identitas baru ke profil pengguna yang ada. Sekarang pengguna ini akan memiliki dua Identitas Federasi: satu menggunakan penyedia Facebook, satu lagi menggunakan penyedia Google.
Apa pro dan kontra dari opsi (B) vs. opsi (C)? Di bawah ini adalah titik awal untuk perbandingan ini. Pro / kontra apa yang saya lewatkan?
Gabungkan Identitas
- Pro
- Pencarian lebih sederhana / lebih cepat karena hanya ada satu ID Identitas per pengguna yang harus diindeks di bagian belakang
- Saya menganggap ini adalah solusi paling aman?
- Menipu
- Proses penggabungan itu sendiri tampaknya rumit dan rawan kesalahan. Misalnya, setelah penggabungan, jika ID baru "memenangkan" penggabungan, maka kita harus mengganti ID lama dengan yang baru di profil pengguna ... dan jika terjadi kesalahan selama proses itu kita mungkin tertinggal keadaan tidak dapat dipulihkan di mana Cognito hanya tahu tentang ID baru (gabungan) tetapi database kami hanya tahu tentang yang lama.
- UX yang lebih kompleks di mana pengguna harus masuk (meskipun hanya sekali) ke akun Facebook dan Google di sesi yang sama untuk menautkan akun tersebut.
- Setiap perubahan selanjutnya pada penautan harus melalui Cognito API
Tetap Terpisah
- Pro
- UX yang lebih sederhana: kita dapat menautkan akun sosial dengan mencocokkan alamat email; tidak perlu keduanya masuk dalam satu sesi
- Dapat mengontrol penautan hanya dalam database back-end kami, yang akan memudahkan pembuatan alat admin yang menambahkan / menghapus / mengubah identitas-> tautan profil pengguna daripada harus memanggil API Cognito untuk melakukan tindakan ini.
- Tidak ada risiko Cognito tidak sinkron dengan DB back-end kami. Jika penautan gagal, pengguna dapat mencoba lagi.
- Menipu
- Perlu banyak: 1 indeks untuk memetakan ID Identitas -> Profil Pengguna, bukan satu kolom yang diindeks
- Apakah ini solusi yang kurang aman? Jika ya, mengapa?
- Apakah ini lebih mahal dalam biaya AWS? Jika ya, mengapa?
Saya condong ke solusi "Tetap Terpisah" karena tampaknya lebih sederhana untuk diterapkan (tidak ada alur kerja UX tambahan) dan lebih mudah bagi pengguna (untuk alasan yang sama: tidak ada alur kerja UX baru). Apa ini salah?
Jawaban
Sangat sulit memberi Anda jawaban, saya pikir Anda telah memberikan pro dan kontra utama dari semua solusi yang mungkin.
Saya hanya akan mencoba mengklarifikasi beberapa saja, yang saya anggap kunci untuk memilih satu solusi dan bukan yang lain.
Pertama-tama, tunjukkan bahwa saya juga lebih suka solusi simpan terpisah. Izinkan saya mencoba menjelaskan alasannya.
Dari sudut pandang UX, jelas bahwa solusi simpan terpisah adalah pendekatan yang jauh lebih baik bagi pengguna. Untuk menggabungkan identitas dari penyedia sosial yang berbeda, pengguna harus masuk dengan mereka, dalam alur kerja pendaftaran aplikasi yang lebih kompleks. Tetapi proses ini dimotivasi hanya untuk keputusan teknis, dan itu tidak akan memberikan manfaat nyata apa pun kepada pengguna.
Menurut saya solusi yang jauh lebih baik dan sederhana adalah dengan hanya menyertakan pemetaan antara setiap identitas dan email terkait saat Anda mengusulkan dalam solusi simpan terpisah, dan biarkan pengguna masuk ke aplikasi dengan penyedia yang dia sukai, secara transparan " menggabungkan ", dalam kode aplikasi Anda, semua mekanisme masuk ini. Persyaratan ini dapat dengan mudah dicapai terlepas dari jenis sistem informasi dasar yang Anda gunakan untuk menyimpan informasi pengguna.
Tolong, pikirkan juga apa yang akan terjadi jika Anda perlu memasukkan penyedia sosial lain yang berbeda dalam aplikasi Anda dan pengguna yang sudah ada ingin masuk ke aplikasi Anda dengan penyedia baru itu: bagaimana identitas akan digabungkan? Haruskah pengguna mengulangi proses tersebut lagi?
Selain itu, fungsionalitas penggabungan identitas adalah sesuatu yang sangat spesifik untuk Cognito. Jika Anda mengadopsi solusi penggabungan, Anda mengambil risiko untuk menggabungkan aplikasi Anda dengan AWS dan AWS Cognito. Jika Anda perlu memindahkan aplikasi Anda ke penyedia cloud lain atau penerapan lokal, Anda mungkin tidak akan memiliki kemampuan untuk membuat asosiasi seperti itu. Sekali lagi, pemetaan antara beberapa jenis informasi identitas dan model pengguna internal Anda yang diadopsi dalam solusi pisahkan tampaknya seperti pendekatan yang jauh lebih baik dan portabel.
Risiko tidak sinkron dengan Cognito bisa menjadi masalah besar lainnya. Apa mekanisme pemulihannya?
Satu-satunya kelemahan nyata dari solusi terpisah mungkin adalah Anda kemungkinan akan dikenakan lebih banyak biaya dari AWS. Seperti yang Anda lihat di dokumentasi harga produk , AWS akan menagih Anda untuk setiap pengguna aktif bulanan (MAU). Jika Anda memiliki lebih banyak identitas, seperti solusi simpan terpisah, kemungkinan akan ada lebih banyak MAU dan Anda mungkin dikenakan biaya lebih tinggi. Bagaimanapun, biaya ini tidak akan jauh lebih tinggi dan, bagaimanapun, saya percaya bahwa keuntungan yang ditawarkan oleh solusi terpisah akan mengkompensasi kenaikan harga minimum ini.
Terakhir, menurut saya solusi simpan terpisah adalah opsi yang kurang aman: meskipun tampaknya Anda menggabungkan identitas untuk memungkinkan pengguna Anda berinteraksi dengan layanan AWS, kebijakan dan asumsi peran yang sama akan berlaku terlepas dari identitas sebenarnya yang diberikan pengguna .
Saya pikir solusi penggabungan akan paling cocok untuk skenario di mana Anda memiliki federasi dan perlu mengidentifikasi pengguna secara unik terlepas dari bagaimana mereka mengautentikasi, tetapi mungkin untuk menegakkan beberapa jenis kebijakan (asumsi peran khusus, dll.) Terkait dengan penggunaan sumber daya berbasis AWS hanya pada identitas spesifik tersebut, dan mungkin, saat Anda tidak memiliki backend aplikasi yang tersedia.
Terlepas dari solusi yang akhirnya diadopsi, faktor kunci keberhasilannya adalah mempertahankan model pengguna dan logika terkait sebisa mungkin independen dari mekanisme yang digunakan untuk mengautentikasi pengguna: solusi tetap terpisah juga membantu untuk berpikir dengan cara itu.
Dari sudut pandang pengguna, dapat terasa sangat membingungkan dan tidak nyaman untuk masuk melalui penyedia kedua hanya untuk menemukan bahwa mereka tidak memiliki konten sebelumnya. Dari sudut pandang ini saya pikir penggabungan akan menjadi tujuan akhir terbaik.
Sekarang dari sudut pandang teknis saya telah mencoba ini dan menemukan bahwa ini cukup merepotkan. Saya berhasil menggabungkan identitas ketika pengguna pertama kali masuk dengan email dan kemudian dengan sosial tetapi tidak sebaliknya. Saya kira satu-satunya pilihan adalah memiliki pemicu lambda pra-pendaftaran yang memeriksa DB untuk login sebelumnya pada email tertentu dan meminta pengguna untuk login juga untuk melakukan penggabungan atau hanya melanjutkan login pada yang ada. Ini lebih mudah untuk dikatakan daripada dilakukan jika ada lebih dari satu login yang sudah ada sebelumnya.
Mengenai pertanyaan siapa yang "memenangkan" penggabungan, Itu selalu yang sudah ada sebelumnya. Juga pada akhirnya tidak masalah karena semua login akan menggunakan ID gabungan cognito yang sama melalui panggilan.