สถาปัตยกรรมสำหรับการรวมบัญชีผู้ใช้หลายบัญชีเข้าด้วยกัน

ตกลงฉันมีเว็บไซต์ที่คุณสามารถลงทะเบียนด้วยตัวคุณเองและเข้าสู่ระบบ นอกจากนี้คุณยังสามารถเข้าสู่ระบบด้วยบัญชี facebook, twitter หรือ linkedin ของคุณ

เป็นสิ่งสำคัญที่ผู้ใช้จะต้องลงทะเบียนเพียงหนึ่งบัญชี ดังนั้นฉันต้องการรวมบัญชีของผู้ใช้หากพวกเขาใช้วิธีการต่าง ๆ ในการเข้าสู่ระบบ ทางออกที่ดีที่สุดในการแก้ปัญหานี้คืออะไร?

ตัวอย่างเช่นผู้ใช้เข้าสู่ระบบด้วยบัญชี Facebook ของเขา ฉันใช้ข้อมูลเพื่อลงทะเบียนบัญชีสำหรับเขาโดยอัตโนมัติ ฉันควรส่งอีเมลพร้อมชื่อผู้ใช้และรหัสผ่านของเว็บไซต์ของเราหรือไม่ (หากเป็นไปตามนโยบายของ Facebook) ฉันควรให้หน้าจอที่สองที่พวกเขาสามารถกรอกชื่อผู้ใช้และรหัสผ่านได้หรือไม่ แต่นั่นไม่ใช่แนวคิดในการเข้าสู่ระบบด้วยบัญชี Facebook ของคุณ ควรทำให้ขั้นตอนของคุณง่ายขึ้นในการเข้าร่วม

อาจเป็นไปได้ว่าผู้ใช้ลงทะเบียนตัวเองบนเว็บไซต์ของเราและครั้งต่อไปที่เขาลงชื่อเข้าใช้ด้วยบัญชีตัวสั่นด้วยความตื่นเต้น ฉันจะรวม 2 บัญชีเหล่านี้เข้าด้วยกันได้อย่างไร วิธีที่ดีที่สุดคืออะไร

ดังนั้นโดยทั่วไปคำถามของฉันคือฉันได้ 4 วิธีที่แตกต่างกันที่ผู้ใช้เป็นสมาชิกของเว็บไซต์ของเรา ฉันจะแน่ใจได้อย่างไรว่าทั้ง 4 วิธีนี้สร้างเพียงหนึ่งบัญชีหากผู้ใช้ตัดสินใจที่จะใช้หลายวิธี การไหลที่ดีที่สุดคืออะไรเพื่อให้แน่ใจว่าผู้ใช้จะไม่สร้างความยุ่งยากให้กับตัวเอง?

แก้ไข:

3 ปีหลังจากที่ฉันถามคำถามนี้ฉันจะให้คำตอบตัวเองในชุดของบทความ: 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/

ฉันกำลังเผชิญกับงานเดียวกันที่แน่นอนในขณะนี้ การออกแบบของฉันค่อนข้างเรียบง่าย แต่ใช้งานได้ดี

แนวคิดหลักคือแบบจำลองสำหรับข้อมูลประจำตัวของเว็บไซต์ท้องถิ่นและข้อมูลประจำตัวของเว็บไซต์บุคคลที่สามจะถูกแยกออก แต่จะมีการเชื่อมโยงในภายหลัง ดังนั้นผู้ใช้ทุกคนที่เข้าสู่เว็บไซต์จะมีข้อมูลประจำตัวในท้องถิ่นซึ่งจับคู่กับข้อมูลประจำตัวของเว็บไซต์บุคคลที่สาม

เร็กคอร์ดเอกลักษณ์โลคัลมีข้อมูลขั้นต่ำ - อาจเป็นฟิลด์เดียว - เพียงคีย์หลัก (สำหรับแอปพลิเคชันของฉันฉันไม่สนใจอีเมลของผู้ใช้ชื่อหรือวันเกิด - ฉันแค่อยากรู้ว่าพวกเขาเป็นบุคคลที่ลงชื่อเข้าใช้บัญชีนี้มาตลอด)

ข้อมูลเฉพาะตัวของบุคคลที่สามมีข้อมูลที่เกี่ยวข้องกับการตรวจสอบสิทธิ์กับบุคคลที่สามเท่านั้น สำหรับ OAuth โดยทั่วไปจะหมายถึงตัวระบุผู้ใช้ (เช่นรหัสอีเมลหรือชื่อผู้ใช้) และตัวระบุบริการ (ระบุว่าไซต์หรือบริการใดได้รับการรับรองความถูกต้องด้วย) ในส่วนอื่น ๆ ของแอปพลิเคชั่นนอกฐานข้อมูลนั้นตัวระบุบริการนั้นจะถูกจับคู่กับวิธีการดึงตัวระบุผู้ใช้ที่เกี่ยวข้องจากบริการนั้นและนั่นคือวิธีการตรวจสอบความถูกต้อง สำหรับ OpenID เราใช้วิธีการเดียวกันยกเว้นวิธีการตรวจสอบความถูกต้องโดยทั่วไป (เนื่องจากเราสามารถดำเนินการโปรโตคอลเดียวกันได้เกือบทุกครั้งยกเว้นว่าเราใช้ URL ตัวตนที่แตกต่างกันและนั่นคือตัวระบุบริการของเรา)

ในที่สุดฉันจะเก็บบันทึกข้อมูลประจำตัวของบุคคลที่สามที่จับคู่กับข้อมูลประจำตัวของท้องถิ่น ในการสร้างเรกคอร์ดเหล่านี้โฟลว์จะมีลักษณะดังนี้:

• ผู้ใช้ล็อกอินเป็นครั้งแรกโดยใช้ข้อมูลประจำตัวของบุคคลที่สาม เรกคอร์ดโลคัลเอกลักษณ์ถูกสร้างขึ้นจากนั้นเร็กคอร์ดเอกลักษณ์บุคคลที่สามจากนั้นจะถูกจับคู่
• ในแผงควบคุมผู้ใช้จะได้รับโอกาสในการเชื่อมโยงบัญชีโดยเข้าสู่บริการของบุคคลที่สาม (ค่อนข้างตรงไปตรงมาว่ามันทำงานอย่างไร)
• ในสถานการณ์ที่ผู้ใช้สร้างหลายบัญชีโดยไม่ได้ตั้งใจการแก้ปัญหาค่อนข้างง่าย ในขณะที่ผู้ใช้เข้าสู่ระบบในบัญชีใดบัญชีหนึ่งเขาเข้าสู่ระบบอื่นที่เขาเคยใช้ในการเข้าสู่เว็บไซต์ (ผ่านคุณสมบัติแผงควบคุมด้านบน) บริการเว็บตรวจพบการปะทะกันนี้ (ว่าข้อมูลประจำตัวในเครื่องของผู้ใช้ที่เข้าสู่ระบบแตกต่างจากข้อมูลประจำตัวในท้องถิ่นที่เชื่อมโยงกับข้อมูลประจำตัวของบุคคลที่สามที่เพิ่งเข้าสู่ระบบ) และผู้ใช้จะได้รับพร้อมท์

การรวมบัญชีเป็นเรื่องของการผสานแต่ละเขตข้อมูลของข้อมูลประจำตัวท้องถิ่น (ซึ่งจะแตกต่างกันไปจากแอปพลิเคชันไปยังแอปพลิเคชันและควรจะง่ายถ้าคุณมีเพียงสองสามฟิลด์ในบันทึกข้อมูลประจำตัวท้องถิ่นของคุณ) มีการเชื่อมโยงกับตัวตนในท้องถิ่นผลลัพธ์

ฉันมักจะพบว่ามีเว็บไซต์จำนวนมากที่รวมตัวกันโดยอิงจากอีเมลเนื่องจากปัจจัยการรวมที่ทับซ้อนกัน

ฉันสามารถเห็นว่านี่เป็นตัวเลือกที่ทำงานได้ แต่มันก็ขึ้นอยู่กับความต้องการของคุณในการรวม ที่อยู่อีเมลเป็นวิธีการหลักที่ผู้คนใช้ในการตรวจสอบการเปลี่ยนแปลงข้อมูลสำคัญในเว็บไซต์ของคุณเช่นการเปลี่ยนรหัสผ่านการยกเลิกบริการยอดเงินในบัญชีต่ำ ฯลฯ ... เกือบจะเหมือนกับระบบหมายเลขประกันสังคมของเว็บ แต่มีความสามารถในการสื่อสาร . วัฒนธรรม: ฉันคิดว่ามันสมเหตุสมผลที่จะถือว่าอีเมลเป็นเอกลักษณ์ที่ไม่ซ้ำใครในบริการตรวจสอบสิทธิ์ OAuth ได้รับมันเป็นรูปแบบการเข้าสู่ระบบสำหรับ Facebook และ Google ขอ

กระบวนการคิดปัจจุบันของฉัน

หน้าเข้าสู่ระบบมี 3 ตัวเลือก

• การเป็นสมาชิกเว็บไซต์ของคุณเอง
• เข้าสู่ระบบด้วย facebook
• เข้าสู่ระบบด้วย google

1) การเข้าสู่ระบบของผู้ใช้เป็นครั้งแรก: ทริกเกอร์โฟลว์การลงทะเบียนที่บัญชีถูกสร้างและเติมข้อมูลในครั้งแรก

 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) ในเวลาอื่น ๆ ผู้ใช้กลับมา แต่ตัดสินใจที่จะคลิกเข้าสู่ระบบของ Google

      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) ตอนนี้คุณได้รวมบัญชีที่คุณเชื่อถืออีเมลในรายการฐานข้อมูลของคุณเหมือนกับที่คุณเชื่อถือจากการเข้าสู่ระบบภายนอก

ดังนั้นสำหรับการเข้าสู่ระบบที่ตามมา

ดังนั้นถ้าคุณมีการเข้าสู่ระบบภายนอกก่อนแล้วคุณต้องการให้ผู้ใช้สามารถเข้าสู่ระบบด้วยรหัสผ่านในภายหลังหรือไม่

ฉันเห็นสองวิธีง่าย ๆ ในการทำเช่นนี้

• ในการเข้าสู่ระบบครั้งแรกใด ๆ เมื่อบัญชีถูกสร้างขึ้นจากการตรวจสอบภายนอกขอให้พวกเขาสำหรับรหัสผ่านเพื่อกรอกรายการแรกในใบสมัครของคุณ

• หากพวกเขาลงทะเบียนโดยใช้ facebook หรือ google ก่อนแล้วอย่างใดต้องการลงทะเบียนโดยใช้แบบฟอร์มการลงทะเบียนของเว็บไซต์ของคุณเอง ตรวจสอบว่าที่อยู่อีเมลที่พวกเขาป้อนนั้นมีอยู่แล้วถามพวกเขาสำหรับรหัสผ่านและส่งอีเมลยืนยันพวกเขาหลังจากการลงทะเบียนเสร็จสมบูรณ์

ฉันเคยผ่านสิ่งนี้มาแล้วด้วย sled.com มีปัญหาหลายประการเกี่ยวกับการสร้างบัญชีและการสนับสนุนบัญชีบุคคลที่สามหลายบัญชีเพื่อเข้าสู่ระบบ บางส่วนของพวกเขาคือ:

• คุณต้องการที่จะสนับสนุนทั้งรหัสผ่านท้องถิ่นและเข้าสู่ระบบบุคคลที่สาม?

สำหรับ sled.com ฉันได้ตัดสินใจวางรหัสผ่านในท้องที่เนื่องจากมีค่าเล็กน้อยที่เพิ่มเข้ามาและค่าใช้จ่ายเพิ่มเติมในการรักษาความปลอดภัยของแบบฟอร์มการป้อนรหัสผ่าน มีการโจมตีที่รู้จักกันหลายครั้งสำหรับการทำลายรหัสผ่านและหากคุณจะแนะนำรหัสผ่านคุณต้องแน่ใจว่าพวกเขาจะไม่แตกหักง่าย คุณต้องเก็บไว้ในแฮชแบบทางเดียวหรือสิ่งที่คล้ายกันเพื่อป้องกันไม่ให้รั่วไหล

• คุณต้องการความยืดหยุ่นในการสนับสนุนบัญชีบุคคลที่สามหลายบัญชีหรือไม่

ดูเหมือนว่าคุณได้เลือกผู้ให้บริการเข้าสู่ระบบสามคน: Facebook, Twitter และ LinkedIn เยี่ยมมากเพราะหมายความว่าคุณกำลังใช้ OAuth และทำงานกับผู้ให้บริการที่เชื่อถือได้ ฉันไม่ใช่แฟนของ OpenID คำถามที่เหลือคือถ้าคุณต้องการสนับสนุนบัญชีบุคคลที่สามหลายบัญชีจากผู้ให้บริการรายเดียวกัน (เช่นบัญชีท้องถิ่นหนึ่งบัญชีที่เชื่อมโยงกับบัญชี Twitter สองบัญชี) ฉันถือว่าไม่มี แต่ถ้าคุณทำคุณจะต้องรองรับในรูปแบบข้อมูลของคุณ

สำหรับ Sled เราสนับสนุนการลงชื่อเข้าใช้ด้วย Facebook, Twitter และ Yahoo! และภายในแต่ละบัญชีผู้ใช้จะมีรหัสสำหรับแต่ละคีย์: {"_id": "djdjd99dj", "yahoo": "dj39djdj", twitter: "3723828732", "facebook": "12837287"} เราตั้งค่าข้อ จำกัด มากมายเพื่อให้แน่ใจว่าบัญชีบุคคลที่สามแต่ละบัญชีสามารถเชื่อมโยงกับบัญชีท้องถิ่นเดียวเท่านั้น

หากคุณจะอนุญาตให้มีหลายบัญชีจากผู้ให้บริการบุคคลที่สามเดียวกันคุณจะต้องใช้รายการหรือโครงสร้างอื่น ๆ เพื่อสนับสนุนสิ่งนั้นและด้วยข้อ จำกัด อื่น ๆ ทั้งหมดเพื่อให้แน่ใจว่ามีเอกลักษณ์

• จะเชื่อมโยงหลายบัญชีได้อย่างไร

ครั้งแรกที่ผู้ใช้สมัครใช้บริการของคุณพวกเขาจะไปที่ผู้ให้บริการบุคคลที่สามก่อนแล้วจึงกลับมาพร้อมกับรหัสบุคคลที่สามที่ผ่านการตรวจสอบแล้ว จากนั้นคุณสร้างบัญชีท้องถิ่นสำหรับพวกเขาและรวบรวมข้อมูลอื่น ๆ ที่คุณต้องการ เรารวบรวมที่อยู่อีเมลของพวกเขาและขอให้พวกเขาเลือกชื่อผู้ใช้ในท้องถิ่น (เราพยายามเติมข้อมูลฟอร์มล่วงหน้าด้วยชื่อผู้ใช้ที่มีอยู่จากผู้ให้บริการรายอื่น) การมีตัวระบุท้องถิ่นบางรูปแบบ (อีเมลชื่อผู้ใช้) เป็นสิ่งสำคัญมากสำหรับการกู้คืนบัญชีในภายหลัง

เซิร์ฟเวอร์รู้ว่านี่เป็นการเข้าสู่ระบบครั้งแรกหากเบราว์เซอร์ไม่มีเซสชันคุกกี้ (ใช้ได้หรือหมดอายุ) สำหรับบัญชีที่มีอยู่และไม่พบบัญชีบุคคลที่สามที่ใช้ เราพยายามแจ้งให้ผู้ใช้ทราบว่าพวกเขาไม่ได้เป็นเพียงการเข้าสู่ระบบ แต่กำลังสร้างบัญชีใหม่เพื่อที่ว่าหากพวกเขามีบัญชีอยู่แล้วพวกเขาหวังว่าจะหยุดชั่วคราวและเข้าสู่ระบบด้วยบัญชีที่มีอยู่แทน

เราใช้ขั้นตอนเดียวกันเพื่อเชื่อมโยงบัญชีเพิ่มเติม แต่เมื่อผู้ใช้กลับมาจากบุคคลที่สามการมีคุกกี้เซสชันที่ถูกต้องจะใช้เพื่อแยกความแตกต่างระหว่างความพยายามเชื่อมโยงบัญชีใหม่กับการดำเนินการเข้าสู่ระบบ เราอนุญาตให้บัญชีบุคคลที่สามหนึ่งบัญชีสำหรับแต่ละประเภทเท่านั้นและหากมีการเชื่อมโยงหนึ่งบัญชีให้ปิดกั้นการกระทำ ไม่น่าจะมีปัญหาเพราะอินเทอร์เฟซการเชื่อมโยงบัญชีใหม่ถูกปิดใช้งานถ้าคุณมีหนึ่ง (ต่อผู้ให้บริการ) แต่ในกรณี

• จะรวมบัญชีได้อย่างไร

หากผู้ใช้พยายามเชื่อมโยงบัญชีบุคคลที่สามใหม่ซึ่งเชื่อมโยงกับบัญชีท้องถิ่นแล้วคุณเพียง แต่แจ้งให้พวกเขายืนยันว่าพวกเขาต้องการรวมสองบัญชี (สมมติว่าคุณสามารถจัดการรวมกับชุดข้อมูลของคุณได้) กว่าเสร็จแล้ว) คุณยังสามารถมอบปุ่มพิเศษให้พวกเขาเพื่อขอให้ทำการผสาน แต่ในทางปฏิบัติสิ่งที่พวกเขาทำคือการเชื่อมโยงบัญชีอื่น

นี่เป็นเครื่องรัฐที่เรียบง่าย ผู้ใช้กลับมาจากบุคคลที่สามด้วยรหัสบัญชีบุคคลที่สาม ฐานข้อมูลของคุณสามารถอยู่ในสถานะใดสถานะหนึ่งในสามสถานะ:

1. บัญชีเชื่อมโยงกับบัญชีท้องถิ่นและไม่มีคุกกี้เซสชัน -> เข้าสู่ระบบ
2. บัญชีเชื่อมโยงกับบัญชีท้องถิ่นและมีเซสชันคุกกี้ -> ผสาน
3. บัญชีไม่ได้เชื่อมโยงกับบัญชีท้องถิ่นและไม่มีคุกกี้เซสชัน -> ลงชื่อสมัครใช้

4. บัญชีไม่ได้เชื่อมโยงกับบัญชีท้องถิ่นและคุกกี้เซสชันมีอยู่ -> การเชื่อมโยงบัญชีเพิ่มเติม

   • วิธีการกู้คืนบัญชีกับผู้ให้บริการบุคคลที่สาม

นี่คือดินแดนทดลอง ฉันไม่ได้เห็น UX ที่สมบูรณ์แบบสำหรับบริการนี้เพราะบริการส่วนใหญ่ให้รหัสผ่านในพื้นที่ถัดจากบัญชีบุคคลที่สามดังนั้นจึงมุ่งเน้นไปที่กรณีการใช้ "ลืมรหัสผ่านของฉัน" ไม่ใช่ทุกอย่างที่ผิดพลาด

ด้วย Sled เราได้เลือกใช้ "ต้องการความช่วยเหลือในการลงชื่อเข้าใช้หรือไม่" และเมื่อคุณคลิกถามผู้ใช้สำหรับอีเมลหรือชื่อผู้ใช้ของพวกเขา เราค้นหาและหากเราพบบัญชีที่ตรงกันให้ส่งลิงก์ให้กับผู้ใช้ซึ่งสามารถล็อกอินเข้าสู่บริการโดยอัตโนมัติ (ดีครั้งเดียว) เมื่อเข้ามาเราจะพาพวกเขาไปยังหน้าการเชื่อมโยงบัญชีบอกพวกเขาว่าพวกเขาควรพิจารณาและอาจเชื่อมโยงบัญชีเพิ่มเติมและแสดงให้พวกเขาเห็นบัญชีบุคคลที่สามที่พวกเขามีการเชื่อมโยงแล้ว

ทั้งสองวิธีในการรวมบัญชีอัตโนมัติทำให้มีช่องโหว่ที่ค่อนข้างใหญ่ซึ่งจะอนุญาตให้บางคนเข้าครอบครองบัญชี พวกเขาทั้งคู่ดูเหมือนจะสมมติว่าผู้ใช้เป็นคนที่พวกเขาพูดเมื่อพวกเขาเสนอตัวเลือกการผสานให้กับผู้ใช้ที่ลงทะเบียน

คำแนะนำของฉันในการลดความเสี่ยงคือการขอให้ผู้ใช้รับรองความถูกต้องกับหนึ่งในผู้ให้บริการข้อมูลที่เป็นที่รู้จักก่อนที่จะทำการผสานเพื่อตรวจสอบตัวตนของผู้ใช้

ตัวอย่าง: ผู้ใช้ A ลงทะเบียนด้วยข้อมูลประจำตัว Facebook บางครั้งพวกเขากลับไปที่ไซต์ของคุณและพยายามเข้าถึงด้วย Windows Live ID และเริ่มกระบวนการลงทะเบียน ไซต์ของคุณจะแจ้งให้ผู้ใช้ A ด้วย ... ดูเหมือนว่าคุณลงทะเบียนกับ Facebook ก่อนหน้านี้ กรุณาเข้าสู่ระบบด้วย Facebook (ลิงก์ให้) และเราสามารถผสาน Windows Live ID ของคุณเข้ากับโปรไฟล์ที่มีอยู่

อีกทางเลือกหนึ่งคือการจัดเก็บความลับที่ใช้ร่วมกัน (รหัสผ่าน / คำถามส่วนตัว) ในการลงทะเบียนครั้งแรกที่ผู้ใช้จะต้องให้เมื่อรวมตัวตน นอกจากนี้ยังหมายความว่าคุณต้องจัดการสถานการณ์ที่ผู้ใช้ไม่จำความลับที่ใช้ร่วมกันและเวิร์กโฟลว์ที่สอดคล้องกับมัน

โพสต์ส่วนใหญ่ค่อนข้างเก่าและฉันคิดว่าบริการการรับรองความถูกต้อง Firebaseฟรีของ Google ยังไม่มีอยู่ หลังจากยืนยันด้วย OAuth คุณจะส่งโทเค็น OAuth ไปที่นั้นและรับรหัสผู้ใช้ที่ไม่ซ้ำซึ่งคุณสามารถเก็บไว้เพื่อการอ้างอิง ผู้ให้บริการที่รองรับ ได้แก่ Google, Facebook, Twitter, GitHub และมีตัวเลือกในการลงทะเบียนผู้ให้บริการที่กำหนดเองและไม่ระบุชื่อ

คำตอบที่ยอดเยี่ยมและแหล่งข้อมูลด้านบน ผลงานของฉันได้รับการสรุปที่นี่ ... https://github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR: แยกบัญชีและสคีมาของบุคคล บัญชี, อีเมลและ OAuth 2 รูปแบบ

บัญชี - รับรองความถูกต้อง -> บุคคล

คุณควรอนุญาตให้เข้าสู่ระบบจากหนึ่งบัญชีจากนั้นเมื่อเข้าสู่ระบบให้ตัวเลือกในการเพิ่มบัญชีอื่นที่แตกต่างเพื่อผสานกับมัน