วางแผนสถาปัตยกรรมของคุณ

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

โมเดลธุรกิจของคุณคืออะไร และใครคือฝ่ายสำคัญและผู้มีส่วนได้ส่วนเสีย?

โดยทั่วไปมีโมเดลธุรกิจหลัก 2 แบบ คือ B2C และ B2B ซึ่งแต่ละแบบเกี่ยวข้องกับฝ่ายต่าง ๆ ในสถานการณ์การจัดการเอกลักษณ์ที่ซับซ้อน การเข้าใจผู้มีส่วนได้ส่วนเสียหลักเหล่านี้จะช่วยให้คุณออกแบบระบบที่มุ่งเน้นประสบการณ์ผู้ใช้และครอบคลุมทุกแง่มุมของการจัดการเอกลักษณ์

B2C

ในแอปพลิเคชัน B2C การจัดการเอกลักษณ์มักจะตรงไปตรงมาและเกี่ยวข้องกับเพียงสองฝ่ายเท่านั้น

นักพัฒนา (คุณ)

หมายถึง ผู้ดูแลและผู้ร่วมงาน Logto Console — โดยปกติคือคุณและทีมพัฒนาของคุณ — ทำหน้าที่จัดการและรักษาความปลอดภัยกลุ่มเอกลักษณ์ผู้ใช้ และทำงานโดยตรงกับฐานข้อมูลเอกลักษณ์ คุณสามารถจัดการเอกลักษณ์ลูกค้าได้โดยตรงใน Logto Console หรือพัฒนาฟีเจอร์เพิ่มเติมผ่าน Logto Management API

ผู้บริโภคของคุณ

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

B2B

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

นักพัฒนา (คุณ)

ยังคงหมายถึง ผู้ดูแลและผู้ร่วมงาน Logto Console แม้ว่าแอดมินขององค์กรจะสามารถจัดการเอกลักษณ์ได้ แต่นักพัฒนายังคงสามารถจัดการเอกลักษณ์ลูกค้าได้โดยตรงใน Logto Console หรือผ่านการพัฒนาฟีเจอร์เพิ่มเติมด้วย Logto Management API

ลูกค้าของคุณ (แอดมินองค์กร)

ลูกค้าของคุณคือหน่วยธุรกิจที่แทน “องค์กร” ในแอปแบบหลายผู้เช่า เช่น เวิร์กสเปซ ใน Slack หรือ Notion โดยแต่ละเวิร์กสเปซมักมีบทบาทหลายบทบาทและมีแอดมินหนึ่งคนหรือมากกว่าที่จัดการพนักงานหรือผู้ใช้ ในเนื้อหาต่อไปนี้ เราจะเรียกบุคคลที่สามารถจัดการเอกลักษณ์สมาชิกว่า "แอดมินองค์กร"

พนักงาน พาร์ทเนอร์ หรือผู้บริโภคของลูกค้าคุณ

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

ในสถานการณ์จริง จากมุมมองของผลิตภัณฑ์ กลุ่มนี้อาจเป็นพนักงานบริษัท พาร์ทเนอร์ทางธุรกิจ หรือแม้แต่ผู้บริโภคที่เกี่ยวข้องกับองค์กร

อื่น ๆ

โมเดลอื่น ๆ เช่น B2B2C อาจเกิดขึ้นจากสองแบบข้างต้นเนื่องจากความซับซ้อน อย่างไรก็ตาม แนวทางยังคงเหมือนเดิม: ทุกการเปลี่ยนแปลงมีรากฐานเดียวกัน

ในบทถัดไป เราจะเจาะลึกสถาปัตยกรรมสองแบบที่พบบ่อยนี้และเน้นฟีเจอร์ที่เกี่ยวข้องซึ่ง Logto รองรับ

สกัดความต้องการด้าน auth ของคุณ

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

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

   เช่น แอปของฉันต้องการฟีเจอร์อะไรบ้าง? ลงชื่อเข้าใช้ด้วยโซเชียล? เข้าสู่ระบบแบบไม่ใช้รหัสผ่าน?

2. คุณ (นักพัฒนา) ต้องการควบคุมการกระทำของลูกค้าในระดับใด?

   เช่น ลูกค้าสามารถอัปเดตและดูแลโปรไฟล์ของตนเองได้หรือไม่? ลูกค้าสามารถเปิด / ปิด MFA ได้เองหรือไม่? พวกเขาสามารถเลือกวิธีลงชื่อเข้าใช้ที่ต้องการได้หรือไม่?

3. คุณต้องการมอบหมายการปรับแต่งประเภทใดให้กับองค์กร? ขึ้นอยู่กับโดเมนและอุตสาหกรรมของผลิตภัณฑ์ รวมถึงความต้องการเฉพาะของลูกค้าแต่ละราย ซึ่งอาจแตกต่างกันไปในแต่ละองค์กร

   เช่น ประสบการณ์การลงชื่อเข้าใช้ควรแตกต่างกันสำหรับแต่ละองค์กรหรือไม่? ถ้าใช่ การปรับแต่งควรจำกัดแค่แบรนด์ หรือรวมถึงความแตกต่างใน flow การยืนยันตัวตนด้วย?

4. คุณต้องการให้แอดมินองค์กรควบคุมการกระทำของสมาชิกในระดับใด?

   เช่น แอดมินองค์กรควรตัดสินใจได้หรือไม่ว่าต้องใช้ MFA? แอดมินควรมีสิทธิ์เปลี่ยนรหัสผ่านของสมาชิกได้หรือไม่?

คุณต้องการระบบเอกลักษณ์เดียวแบบสากลหรือแยกหลายระบบ?

อีกหนึ่งคำถามสำคัญที่ควรคำนึงถึงคือ คุณหรือส่วนหนึ่งของธุรกิจ / ผลิตภัณฑ์ของคุณต้องการระบบเอกลักษณ์เดียวหรือแยกกัน

โดยทั่วไป คำตอบคือระบบเอกลักษณ์เดียวแบบสากล หมายความว่าคุณต้องการเพียง Logto tenant เดียว (หรืออินสแตนซ์ Logto admin console เดียวใน OSS) Logto ถูกออกแบบมาให้รองรับทั้งหลายแอปและหลายองค์กรภายใน tenant เดียว โดยปกติ Logto tenant สำหรับ production หนึ่งตัวก็เพียงพอสำหรับความต้องการส่วนใหญ่ ต่อไปนี้คือตัวอย่างสถานการณ์ที่พบบ่อย:

ฉันต้องการสร้างแอป SaaS แบบหลายผู้เช่า

หากคุณกำลังสร้างแอป SaaS ที่มีแนวคิด “workspace” หรือ “องค์กร” สำหรับลูกค้าแต่ละราย คุณสามารถใช้ “องค์กร” เพื่อจัดการ workspace ของลูกค้าแต่ละรายภายใน tenant เดียว

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

ฉันมีหลายแอปพลิเคชัน

ด้วย Logto คุณสามารถจัดการหลายแอปพลิเคชันภายใน tenant เดียวได้โดยไม่คำนึงถึง

1. ประเภทของแอปพลิเคชัน (เช่น เว็บ โมบาย เดสก์ท็อป ฯลฯ)
2. กรณีการใช้งานและฟังก์ชันของแอป (เช่น แอปสำหรับคนขับ แอปสำหรับผู้โดยสาร ฯลฯ)

ฉันมีลูกค้าองค์กรหลายราย

คุณสามารถใช้ “องค์กร” ร่วมกับ Enterprise SSO เพื่อจัดการลูกค้าองค์กรหลายรายภายใน tenant เดียวได้ โดยการตั้งค่าโดเมนอีเมลสำหรับ Enterprise SSO และใช้ฟีเจอร์ Just-in-Time provisioning คุณสามารถทำให้กระบวนการที่ผู้ใช้ที่มีบัญชี Enterprise SSO เข้าร่วมหรือเข้าสู่องค์กรที่เหมาะสมเป็นไปโดยอัตโนมัติ