Birden çok kullanıcı hesabını bir araya getirmek için mimari

Tamam, kendinizi kaydedebileceğiniz ve giriş yapabileceğiniz bir web sitem var. Ayrıca facebook, twitter veya Linkedin hesabınızla giriş yapabilirsiniz.

Kullanıcıların yalnızca bir hesabının kayıtlı olması önemlidir. Bir şekilde, giriş yapmak için farklı yöntemler kullanıyorlarsa kullanıcıların hesaplarını birleştirmek istiyorum. Bunu çözmek için en iyi çözüm nedir?

Örneğin, kullanıcı Facebook hesabıyla oturum açar. Verileri otomatik olarak bir hesap açmak için kullanıyorum. Web sitemizin kullanıcı adı ve şifresi ile bir e-posta göndermeli miyim? (Bu Facebook politikası ile sorun değilse). Onlara bir kullanıcı adı ve şifre girebilecekleri ikinci bir ekran vermeli miyim? Ancak Facebook hesabınızla giriş yapmanın ardındaki fikir bu değil. Katılma prosedürünüzü basitleştirmelidir.

Kullanıcının web sitemizde kendini kaydetmesi ve bir dahaki sefere twitter hesabıyla oturum açması da mümkündür. Bu 2 hesabı bir hesap olarak nasıl birleştirebilirim? En iyi yol nedir?

Temelde sorum şu: Bir kullanıcının web sitemize üye olması için 4 farklı yolum var. Bir kullanıcı birden çok yol kullanmaya karar verirse, bu 4 yolun hepsinin yalnızca bir hesap oluşturduğundan nasıl emin olabilirim? Kullanıcının kendisi için bir güçlük haline gelmemesini sağlamak için en iyi akış nedir?

Düzenle:

Bu soruyu sorduktan 3 yıl sonra, cevabı kendime bir dizi makalede veriyorum: https://www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social- network-authentication-google /
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/

Şu anda aynı görevle karşı karşıyayım. Çalıştığım tasarım oldukça basit, ama iyi çalışıyor.

Ana fikir, yerel bir site kimliği ve üçüncü taraf site kimlikleri için modellerin yalıtılmış tutulması, ancak daha sonra bağlantılı olmalarıdır. Bu nedenle, siteye giriş yapan her kullanıcının, herhangi bir sayıda üçüncü taraf site kimliğiyle eşleşen yerel bir kimliği vardır.

Yerel kimlik kaydı minimum bilgi içerir - tek bir alan bile olabilir - sadece birincil anahtardır. (Başvurum için, kullanıcının e-postasını, adını veya doğum tarihini umursamıyorum - sadece bu hesaba giriş yapan kişi olduklarını bilmek istiyorum.)

Üçüncü taraf kimlikleri yalnızca bir üçüncü tarafla kimlik doğrulamasıyla ilgili bilgiler içerir. OAuth için bu genellikle bir kullanıcı tanımlayıcısı (kimlik, e-posta veya kullanıcı adı gibi) ve bir hizmet tanımlayıcısı (hangi sitenin veya hizmetin kimliğinin doğrulandığını gösteren) anlamına gelir. Uygulamanın diğer bölümlerinde, veritabanının dışında, bu hizmet tanımlayıcısı, söz konusu hizmetten ilgili kullanıcı tanımlayıcısını almak için bir yöntemle eşleştirilir ve kimlik doğrulaması bu şekilde gerçekleştirilir. OpenID için, aynı yöntemi kullanırız, ancak kimlik doğrulama yöntemi daha genelleştirilir (çünkü neredeyse her zaman tam olarak aynı protokolü gerçekleştirebiliriz - farklı bir kimlik URL'si kullanmamız ve bu bizim hizmet tanımlayıcımızdır).

Son olarak, hangi üçüncü taraf kimliklerinin hangi yerel kimlikle eşleştirildiğinin kayıtlarını tutuyorum. Bu kayıtları oluşturmak için akış şöyle görünür:

• Bir kullanıcı ilk kez bir üçüncü taraf kimliği kullanarak oturum açar. Yerel kimlik kaydı oluşturulur, ardından üçüncü taraf kimlik kaydı oluşturulur ve eşleştirilir.
• Kontrol panelinde, kullanıcıya üçüncü taraf hizmetlerine giriş yaparak bir hesabı bağlama fırsatı sunulur. (Bunun nasıl çalıştığını gayet açık.)
• Kullanıcının farkında olmadan birden fazla hesap oluşturduğu senaryoda, çözüm oldukça basittir. Kullanıcı hesaplardan birinde oturum açmışken, daha önce sitede oturum açmak için kullandığı başka bir hesapta oturum açar (yukarıdaki kontrol paneli özelliği ile). Web hizmeti bu çakışmayı algılar (oturum açan kullanıcının yerel kimliği, yeni oturum açmış olan üçüncü taraf kimliğine bağlı yerel kimlikten farklıdır) ve kullanıcıdan bir hesap birleştirmesi istenir.

Hesapların birleştirilmesi, yerel kimliğin her bir alanını (uygulamadan uygulamaya farklılık gösterecek ve yerel kimlik kayıtlarınızda yalnızca birkaç alanınız varsa kolay olmalıdır) birleştirmek ve daha sonra bağlantılı üçüncü taraf kimliklerini sağlamak meselesidir. sonuçta ortaya çıkan yerel kimliğe bağlıdır.

Çakışan birleştirme faktörü olarak e-postaya dayalı bir çok site bulma eğilimindeyim .

Bunun uygulanabilir bir seçenek olduğunu görebiliyorum, ancak yine de nasıl birleştirileceğine tercihinize bağlı. E-posta Adresi, kullanıcıların sitenizdeki bazı önemli bilgi değişikliklerini doğrulamak için parolanızı değiştirmek, hizmetin feshi, hesap bakiyesi düşük vb. . Kültürel olarak: Bir e-postanın OAuth kimlik doğrulama hizmetlerinde oldukça benzersiz bir kimlik olduğunu varsaymanın makul olduğunu düşünüyorum. Verilen, Facebook ve Google için giriş formlarının istediği şey.

Mevcut düşünce sürecim.

Giriş sayfasında 3 seçenek vardır

• Kendi sitenizin üyeliği
• Facebook ile giriş
• Google ile giriş yapın

1) Kullanıcı ilk kez oturum açar: bir hesabın ilk oluşturulduğu ve doldurulduğu bir kayıt akışını tetikler.

 if the user logins using Facebook (or whatever 3rd party login)
      1) call the Facebook api asking for their information (email, name, etc...) 
      2) create an account membership entry in your database somewhat like this 

         Table = Users
         [ UserId   |       Email             | Password ]
         [    23     | "newuser@coolmail.com" |  *null*  ]

      3) create an external auths entry like so
         *ProviderUserId is the unique id of that user on the provider's site

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]

 if the user wants to create an account with your own registration it would just be this           

         Table = Users
         [ UserId   |       Email           |   Password  ]
         [    23     | newuser@coolmail.com |  myCoolPwd  ]

2) Başka bir zamanda kullanıcı geri döner ancak Google Giriş Sayfasını tıklamaya karar verir

      1) call the Google api asking for their information (email, name, etc...) 

      2) once you get the email, match it up to the userId entry with the existing email 

      3) create an additional External auth entry as such

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]
         [    57           |      23        |    Google    |  "1234854368"     ]

3) Artık veritabanı girişlerinizdeki e-postaya güvendiğiniz hesabı harici girişlerden güvendiğiniz hesapla birleştirdiniz.

Sonraki girişler için

Öncelikle harici girişleriniz varsa ve daha sonra bir kullanıcının daha sonra bir şifre ile giriş yapabilmesini istiyorsanız ne olur?

Bunu yapmanın iki kolay yolunu görüyorum

• Harici bir yetkilendirmeden hesap oluşturulduğunda yapılan ilk girişlerde, uygulamanıza ilk girişlerini tamamlamak için onlardan bir şifre isteyin

• Önceden facebook veya google kullanarak kayıt yaptılarsa, bir şekilde kendi sitenizin kayıt formunu kullanarak kaydolmak istediler. Girdikleri e-posta adresinin zaten mevcut olup olmadığını tespit edin, şifre isteyin ve kayıt tamamlandıktan sonra bir e-posta onayı gönderin.

Bunu sled.com ile yaşadım. Burada hesap oluşturma ve giriş için birden fazla üçüncü taraf hesabını destekleme konusunda birçok sorun var. Onlardan bazıları:

• Hem yerel şifreyi hem de üçüncü taraf girişlerini desteklemeniz mi gerekiyor?

Sled.com için, eklediği küçük değer ve bir şifre giriş formunun güvenliğini sağlamanın ek maliyeti nedeniyle yerel şifreyi bırakmaya karar verdim. Şifreleri kırmak için bilinen birçok saldırı vardır ve şifreleri tanıtacaksanız, bunların kırılmasının kolay olmadığından emin olmalısınız. Ayrıca, sızıntılarını önlemek için bunları tek yönlü bir karma veya benzeri bir yerde saklamanız gerekir.

• Birden çok üçüncü taraf hesabını desteklemede ne kadar esnekliğe izin vermek istiyorsunuz?

Görünüşe göre üç giriş sağlayıcıyı zaten seçmişsiniz: Facebook, Twitter ve LinkedIn. Bu harika çünkü OAuth kullanıyor ve iyi tanımlanmış bir dizi güvenilir sağlayıcıyla çalışıyorsunuz. Ben OpenID hayranı değilim. Geriye kalan soru, aynı sağlayıcıdan birden fazla üçüncü taraf hesabını desteklemeniz gerekip gerekmediğidir (örneğin, iki Twitter hesabının bağlı olduğu bir yerel hesap). Hayır kabul ediyorum, ancak bunu yaparsanız, bunu veri modelinize yerleştirmeniz gerekir.

Sled için Facebook, Twitter ve Yahoo! ve her kullanıcı hesabı içinde her biri için bir anahtar depolayın: {"_id": "djdjd99dj", "yahoo": "dj39djdj", twitter: "3723828732", "facebook": "12837287"}. Her bir üçüncü taraf hesabının yalnızca tek bir yerel hesaba bağlanabilmesini sağlamak için bir grup kısıtlama koyarız.

Aynı üçüncü taraf sağlayıcıdan birden fazla hesaba izin verecekseniz, benzersizliği sağlamak için listeleri ve bununla birlikte tüm diğer kısıtlamaları desteklemek için listeler veya başka yapılar kullanmanız gerekir.

• Birden çok hesap nasıl bağlanır?

Kullanıcı hizmetinize ilk kez kaydolduğunda, önce üçüncü taraf sağlayıcıya gider ve doğrulanmış bir üçüncü taraf kimliğiyle geri gelir. Daha sonra onlar için yerel bir hesap oluşturursunuz ve istediğiniz diğer bilgileri toplarsınız. E-posta adreslerini topluyoruz ve ayrıca yerel bir kullanıcı adı seçmelerini istiyoruz (formu diğer sağlayıcıdan mevcut kullanıcı adlarıyla önceden doldurmaya çalışıyoruz). Daha sonra hesap kurtarma için bir tür yerel tanımlayıcıya (e-posta, kullanıcı adı) sahip olmak çok önemlidir.

Tarayıcı, mevcut bir hesap için bir oturum çerezi (geçerli veya süresi dolmuş) yoksa ve kullanılan üçüncü taraf hesabının bulunamadığında, sunucu ilk kez oturum açtığını bilir. Kullanıcıya sadece giriş yapmadıklarını, ancak yeni bir hesap oluşturduklarını bildirmeye çalışırız, böylece zaten bir hesapları varsa, umarım mevcut hesaplarıyla duraklar ve giriş yaparlar.

Ek hesapları bağlamak için tam olarak aynı akışı kullanırız, ancak kullanıcı üçüncü taraftan geri döndüğünde, yeni bir hesabı bir giriş işlemine bağlama girişimi arasında ayrım yapmak için geçerli bir oturum çerezi varlığı kullanılır. Her türden yalnızca bir üçüncü taraf hesabına izin veriyoruz ve zaten bir tane bağlıysa, işlemi engelleyin. Sorun değil, çünkü zaten bir tane (sağlayıcı başına) varsa, yeni bir hesabı bağlamak için arayüz devre dışı bırakılır, ancak her ihtimale karşı.

• Hesaplar nasıl birleştirilir?

Bir kullanıcı zaten yerel bir hesaba bağlı olan yeni bir üçüncü taraf hesabını bağlamaya çalıştıysa, iki hesabı birleştirmek istediklerini onaylamasını istersiniz (veri kümenizle böyle bir birleştirmeyi yapabileceğinizi varsayarsak - genellikle daha kolay daha iyi). Ayrıca, birleştirme istemek için özel bir düğme de sağlayabilirsiniz, ancak pratikte yaptıkları tek şey başka bir hesabı bağlamaktır.

Bu oldukça basit bir durum makinesidir. Kullanıcı üçüncü taraftan üçüncü taraf hesap kimliğiyle geri döner. Veritabanınız üç durumdan birinde olabilir:

1. Hesap yerel bir hesaba bağlı ve oturum çerezi mevcut değil -> Giriş
2. Hesap yerel bir hesaba bağlı ve bir oturum çerezi var -> Birleştir
3. Hesap yerel bir hesaba bağlı değil ve oturum çerezi mevcut değil -> Kaydol

4. Hesap yerel bir hesaba bağlı değil ve bir oturum çerezi var -> Ek hesap bağlama

   • Üçüncü taraf sağlayıcılarla hesap kurtarma nasıl yapılır?

Bu hala deneysel bölge. Çoğu hizmet hem üçüncü taraf hesaplarının yanında yerel bir parola sağladığından hem de "parolamı unuttum" kullanım durumuna odaklandığından, yanlış gidebilecek her şeye odaklanmadığından bunun için mükemmel bir UX görmedim.

Sled ile "Oturum açmak için yardıma mı ihtiyacınız var?" ve tıkladığınızda kullanıcıdan e-posta veya kullanıcı adını isteyin. Bakıyoruz ve eşleşen bir hesap bulursak, kullanıcıya otomatik olarak hizmette oturum açabilecek bir bağlantıyı e-postayla gönderin (bir kez iyi). Bir kez girdikten sonra, bunları doğrudan hesap bağlama sayfasına götürüyoruz, onlara bir göz atmaları ve potansiyel olarak ek hesapları bağlamaları gerektiğini söyledik ve onlara zaten bağladıkları üçüncü taraf hesaplarını gösterdik.

Hesapları otomatik olarak birleştirmeye yönelik her iki yaklaşım da, birinin hesabı devralmasına izin verecek oldukça büyük bir güvenlik açığı bırakır. Her ikisi de, kayıt yapan bir kullanıcıya birleştirme seçeneği sunduğunda kullanıcının söylediği kişi olduğunu varsayar.

Güvenlik açığını azaltmak için önerim, kullanıcının kimliğini doğrulamak için birleştirme gerçekleştirmeden önce kullanıcıdan bilinen Kimlik Sağlayıcılarından biriyle kimlik doğrulaması istemektir.

Örnek: A Kullanıcısı Facebook kimliğiyle kaydolur. Bir süre sonra sitenize geri döner ve Windows Live ID ile erişmeye ve kayıt işlemini başlatmaya çalışırlar. Siteniz A Kullanıcısını şu şekilde isteyecektir ... Görünüşe göre daha önce Facebook'a kaydoldunuz. Lütfen Facebook ile giriş yapın (bağlantı sağlayın) ve Windows Live ID'nizi mevcut profilinizle birleştirebiliriz.

Başka bir alternatif, kullanıcının kimlikleri birleştirirken sağlaması gereken ilk kayıtta paylaşılan bir sırrı (şifre / kişisel soru) saklamaktır, ancak bu sizi paylaşılan sırları saklama işine geri götürür. Ayrıca, kullanıcının paylaşılan sırrı ve onunla birlikte gelen iş akışını hatırlamadığı senaryoyu ele almanız gerektiği anlamına gelir.

Gönderilerin çoğu oldukça eski ve sanırım Google'ın ücretsiz Firebase Kimlik Doğrulama hizmeti henüz yoktu. OAuth ile doğruladıktan sonra, OAuth jetonunu ona iletir ve referans için saklayabileceğiniz benzersiz bir kullanıcı kimliği alırsınız. Desteklenen sağlayıcılar Google, Facebook, Twitter, GitHub'dır ve özel ve anonim sağlayıcılar kaydetme seçeneği vardır.

Yukarıdaki harika yanıtlar ve kaynaklar. Katkım burada özetleniyor ... https://github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR: ayrı Hesap ve Kişi şemaları. Hesap, E-posta ve OAuth'un 2 çeşidi.

Hesap -doğrulama-> Kişi

Bir hesaptan giriş yapmanıza izin vermelisiniz , ardından giriş yaptığınızda, onunla birleştirmek için farklı bir hesap ekleme seçeneği verin.