สร้างแอปพลิเคชัน SaaS สำหรับผู้เช่าหลายราย: คู่มือฉบับสมบูรณ์ตั้งแต่การออกแบบถึงการใช้งาน

แอปพลิเคชันอย่าง Notion, Slack, หรือ Figma สร้างอย่างไร? แอปพลิเคชัน SaaS สำหรับผู้เช่าหลายรายดูเรียบง่ายในการใช้งาน แต่สร้างเองหรือ? นั่นเป็นเรื่องแตกต่าง

เมื่อฉันเริ่มคิดถึงการสร้างสิ่งที่ซับซ้อนเช่นนี้ สมองฉันก็ระเบิด:

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

"บอส มาคุยเกี่ยวกับการออกแบบผลิตภัณฑ์ในอีกสองสัปดาห์เถอะ ตอนนี้ผมกำลังติดในหล่มอยู่ครับ"

แต่เมื่อฉันเริ่มลงมือทำจริง ๆ ฉันพบว่าไม่ได้ดูน่ากลัวอย่างที่คิด

ฉันเพิ่ง สร้างระบบที่มีฟีเจอร์ทั้งหมดเหล่านี้ในเวลาน้อยกว่า 2 ชั่วโมง!

ฉันจะแสดงให้คุณเห็นชัด ๆ ว่าออกแบบและใช้งานระบบแบบนี้จากฐานได้อย่างไร - และคุณจะประทับใจว่าจริง ๆ แล้วมันง่ายแค่ไหนในปี 2025 ด้วยเครื่องมือสมัยใหม่และแนวทางเชิงสถาปัตยกรรมที่ถูกต้อง

ซอร์สโค้ดทั้งหมดอยู่ท้ายบทความนี้ ไปดูกันเลย!

เราจะเริ่มต้นด้วยผลิตภัณฑ์ SaaS ด้านการจัดทำเอกสารที่เรียกว่า DocuMind

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

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

ฟีเจอร์ที่จำเป็นสำหรับการรับรองความถูกต้องและการอนุญาตของ SaaS มีอะไรบ้าง?#

ก่อนอื่น เรามาทบทวนข้อกำหนดที่จำเป็นกันเถอะ คุณต้องการฟีเจอร์อะไรบ้าง?

สถาปัตยกรรมผู้เช่าหลายราย#

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

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

สมาชิกภาพ#

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

ตัวอย่างเช่น ซาร่าห์ลงชื่อสมัครใช้แอปของคุณด้วยอีเมลของเธอ [email protected] เธอสามารถเป็นสมาชิกของที่ทำงานต่าง ๆ ได้ ถ้าซาร่าห์เป็นส่วนหนึ่งของ Workspace A แต่ไม่ใช่ Workspace B เธอถือว่าเป็นสมาชิกของ Workspace A แต่ไม่ใช่ Workspace B

การออกแบบบทบาทและการอนุญาต#

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

บทบาทเป็นชุดของสิทธิ์ที่ได้รับมอบหมายให้กับสมาชิกในสภาพแวดล้อมผู้เช่าหลายราย

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

1. ผู้ใช้ที่เข้าร่วมองค์กรจะได้รับบทบาท สมาชิก โดยอัตโนมัติ
2. ผู้ใช้คนแรกที่สร้างที่ทำงานจะได้รับบทบาท ผู้ดูแลระบบ โดยอัตโนมัติ

กระบวนการสมัครและเข้าสู่ระบบ#

รับรองกระบวนการลงทะเบียนและการรับรองความถูกต้องที่ใช้งานง่ายและปลอดภัย รวมถึงตัวเลือกการเข้าสู่ระบบและการสมัครพื้นฐาน:

1. เข้าสู่ระบบด้วยอีเมลและรหัสผ่าน: วิธีการเข้าสู่ระบบแบบดั้งเดิมด้วยอีเมลและรหัสผ่าน
2. เข้าสู่ระบบแบบไม่มีรหัสผ่าน: ใช้รหัสการตรวจสอบทางอีเมลเพื่อการเข้าถึงที่ง่ายและปลอดภัย
3. การจัดการบัญชี: ศูนย์บัญชีที่ผู้ใช้สามารถอัปเดตอีเมล รหัสผ่าน และรายละเอียดอื่น ๆ
4. เข้าสู่ระบบผ่านโซเชียล: ตัวเลือกอย่าง Google และ GitHub สำหรับการเข้าสู่ระบบที่รวดเร็ว
5. Multi-Factor Authentication (MFA): เสริมความปลอดภัยโดยอนุญาตให้เข้าสู่ระบบผ่านแอปเพื่อตรวจสอบความถูกต้อง เช่น Duo

การสร้างผู้เช่าและการเชิญสมาชิก#

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

นี่คือไม่กี่กระแสการใช้งานทั่วไปที่คุณต้องพิจารณา:

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

สถาปัตยกรรมเทคนิคและการออกแบบระบบ#

เมื่อเราเข้าใจข้อกำหนดของผลิตภัณฑ์ทั้งหมดแล้ว มาดูวิธีการใช้งานกัน

กำหนดกลยุทธ์การรับรองความถูกต้อง#

การรับรองความถูกต้องดูเป็นเรื่องน่ากลัว ผู้ใช้ต้องการ:

• การเข้าสู่ระบบด้วยอีเมลและรหัสผ่าน
• การเข้าสู่ระบบเพียงคลิกเดียวกับ Google/Github
• การรีเซ็ตรหัสผ่านเมื่อพวกเขาลืม
• การเข้าสู่ระบบทั่วทั้งทีมสำหรับลูกค้าองค์กร
• ...

การสร้างฟีเจอร์พื้นฐานเหล่านี้อาจใช้เวลาสัปดาห์ในการพัฒนา

แต่ตอนนี้ เราไม่จำเป็นต้องสร้างสิ่งเหล่านี้เองอีกแล้ว!

ผู้ให้บริการการรับรองความถูกต้องสมัยใหม่ (ฉันจะเลือก Logto ในครั้งนี้) ได้บรรจุฟีเจอร์ทั้งหมดเหล่านี้ไว้ให้เราแล้ว การกระบวนการรับรองความถูกต้องนั้นตรงไปตรงมา:

จากการพัฒนาหลายสัปดาห์เหลือเพียงการตั้งค่า 15 นาที Logto ดูแลกระบวนการซับซ้อนทั้งหมดให้เรา! เราจะครอบคลุมขั้นตอนการรวมในส่วนการใช้งานที่ภายหลัง ตอนนี้เราสามารถมุ่งเน้นในการสร้างฟีเจอร์หลักของ DocuMind ได้!

สร้างสถาปัตยกรรมผู้เช่าหลายราย#

ระบบองค์กรช่วยให้ผู้ใช้สร้างและเข้าร่วมองค์กรได้หลายแห่ง มาทำความเข้าใจความสัมพันธ์หลักกัน:

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

เปิดใช้งานการควบคุมการเข้าถึงในแอปผู้เช่าหลายราย#

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

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

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

ความสัมพันธ์ของสิทธิ์ดูเป็นเช่นนี้:

เนื่องจากผู้ใช้แต่ละคนต้องการบทบาทของพวกเขาเองในแต่ละองค์กร ความสัมพันธ์ระหว่างบทบาทและองค์กรจะต้องสะท้อนบทบาทที่มอบหมายให้กับผู้ใช้แต่ละคน:

เราได้ออกแบบระบบองค์กรและระบบควบคุมการเข้าถึงแล้ว และตอนนี้เราสามารถเริ่มสร้างผลิตภัณฑ์ของเราได้!

เทคโนโลยีที่ใช้#

ฉันเลือกสแต็คที่รองรับผู้เริ่มต้นและพกพาได้ง่าย:

1. Frontend: React (สามารถย้ายไป Vue/Angular/Svelte ได้ง่าย)
2. Backend: Express (API ที่เรียบง่ายและเข้าใจง่าย)

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

และสำหรับคู่มือต่อไปนี้ ลักษณะเหล่านี้สามารถใช้งานได้กับ: Frontend ใด ๆ Backend ใด ๆ และระบบการรับรองความถูกต้องใด ๆ

เพิ่มกระบวนการรับรองความถูกต้องพื้นฐานในแอปของคุณ#

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

ติดตั้ง Logto ในแอปของคุณ#

ก่อนอื่น ล็อกอินเข้าสู่ Logto Cloud คุณสามารถลงทะเบียนบัญชีฟรีได้หากคุณยังไม่มี สร้างผู้เช่าพัฒนาสำหรับการทดสอบ

ใน Tenant Console คลิกปุ่ม "แอปพลิเคชัน" ด้านซ้าย จากนั้นเลือก React เพื่อเริ่มสร้างแอปพลิเคชันของเรา

ทำตามคำแนะนำบนหน้า คุณสามารถทำการรวบรวม Logto ได้ในประมาณ 5 นาที!

นี่คือโค้ดการรวบรวมของฉัน:

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

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

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

และเรียกฟังก์ชัน signOut จากฮุค useLogto เมื่อต้องการให้ผู้ใช้ออกจากระบบ

ปรับแต่งวิธีการเข้าสู่ระบบและการลงทะเบียน#

ใน Logto Console คลิก "ประสบการณ์การเข้าระบบ" บนเมนูด้านซ้าย แล้วคลิกแท็บ "การลงทะเบียนและการเข้าสู่ระบบ" ในหน้านี้ ให้ทำตามคำแนะนำเพื่อกำหนดวิธีการเข้าสู่ระบบ/การลงทะเบียนของ Logto

และกระบวนการเข้าสู่ระบบจะดูเป็นเช่นนี้:

เปิดใช้งานการตรวจสอบสองขั้นตอน#

ด้วย Logto การเปิดใช้งาน MFA นั้นง่ายมาก เพียงคลิกปุ่ม "การยืนยันตัวตนแบบหลายขั้นตอน" ใน Logto Console แล้วเปิดใช้งานในหน้ายืนยันตัวตนแบบหลายขั้นตอน

และกระบวนการ MFA จะดูเป็นเช่นนี้:

ทุกอย่างง่ายดายมาก! เราได้ตั้งค่าระบบการตรวจสอบผู้ใช้ที่ซับซ้อนในเวลาเพียงไม่กี่นาที!

เพิ่มประสบการณ์องค์กรผู้เช่าหลายราย#

ตอนนี้ผู้คนที่ใช้สินค้าของเรากลุ่มแรก! อย่างไรก็ตาม ผู้ใช้เหล่านี้ยังไม่สังกัดในองค์กรใด ๆ เลย และเรายังไม่ได้สร้างองค์กร

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

ผู้ใช้แต่ละคนสามารถดึงข้อมูลองค์กรของตนจาก Logto ซึ่งทำให้รองรับหลายผู้เช่าได้

ดึงข้อมูลองค์กรของผู้ใช้#

เพื่อดึงข้อมูลองค์กรของผู้ใช้จาก Logto ให้ทำตามสองขั้นตอนนี้:

ประกาศการเข้าถึงข้อมูลองค์กรใน Logto Config ซึ่งทำได้โดยการตั้งค่า scopes และ resources ที่เหมาะสม

ใช้เมธอด fetchUserInfo ของ Logto เพื่อดึงข้อมูลผู้ใช้ รวมถึงข้อมูลองค์กร

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

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

ต่อไปเราจะสร้างองค์กรสำหรับผู้ใช้ของเราและเพิ่มพวกเขาลงในนั้น

ขอบคุณ Logto ที่เราไม่ต้องสร้างความสัมพันธ์องค์กรที่ซับซ้อน เราเพียงแต่ต้องสร้างองค์กรใน Logto และเพิ่มผู้ใช้ในนั้น Logto ดูแลทุกความซับซ้อนให้เรา มีสองวิธีในการสร้างองค์กร:

1. สร้างองค์กรผ่าน Logto Console ด้วยตนเอง
2. ใช้ Logto Management API เพื่อสร้างองค์กร โดยเฉพาะเมื่อออกแบบกระแส SaaS ที่ให้ผู้ใช้สร้างองค์กรของตนเอง (ที่ทำงาน)

สร้างองค์กรใน Logto Console#

คลิกปุ่ม "องค์กร" ที่เมนูด้านซ้ายใน Logto Console สร้างองค์กร

ตอนนี้คุณมีองค์กรแรกของคุณแล้ว

ต่อไป เราจะเพิ่มผู้ใช้ในองค์กรนี้

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

รีเฟรชหน้าแอปของคุณ คุณจะเห็นว่าผู้ใช้อยู่ในองค์กรแล้ว!

ใช้งานประสบการณ์การสร้างองค์กรด้วยตนเอง#

การสร้างองค์กรใน console ไม่เพียงพอ แอป SaaS ของคุณต้องมีกระแสที่ให้ผู้ใช้ปลายทางสร้างและจัดการที่ทำงานของตนเองได้อย่างง่ายดาย เพื่อใช้งานฟังก์ชันนี้ ใช้ Logto Management API

สำหรับคำแนะนำ ตรวจสอบ Interact with Management API เพื่อเตรียมการสื่อสาร API อย่างเป็นทางการกับ Logto

เข้าใจวิธีการสร้างองค์กรด้วยการเชื่อมโยงการรับรองสิทธิ์#

มาดูวิธีการสร้างองค์กรเป็นตัวอย่าง ฟังก์ชันการสร้างองค์กรทำงานอย่างไร:

ฟังก์ชันนี้มีความต้องการสำคัญสองประการเกี่ยวกับการรับรองสิทธิ์:

1. การป้องกัน API ของบริการแบ็กเอนด์:
   • การเข้าถึง Frontend ไปยัง API ของบริการแบ็กเอนด์ของเราต้องการการรับรองสิทธิ์
   • จุดเข้า API ได้รับการป้องกันด้วยการตรวจสอบ Access Token ของ Logto
   • รับรองว่าผู้ใช้ที่ได้รับการยืนยันเท่านั้นที่สามารถเข้าถึงบริการของเราได้
2. การเข้าถึง Logto Management API:
   • บริการแบ็กเอนด์จำเป็นต้องเรียก Logto Management API อย่างปลอดภัย
   • ทำตามคำแนะนำ Interact with Management API สำหรับการติดตั้ง
   • ใช้ Machine-to-Machine authentication เพื่อเข้าถึงข้อมูลรับรอง

ป้องกัน API ของแบ็กเอนด์ของคุณ#

ก่อนอื่น มาสร้างจุดเข้า API ในบริการแบ็กเอนด์ของเราสำหรับการสร้างองค์กร

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

ในแนวคิดของ Logto (และ OAuth 2.0) บริการแบ็กเอนด์ของเราทำหน้าที่เป็น resource server ผู้ใช้เข้าถึง resource server ของ DocuMind ด้วย Access token จาก frontend (in frontend) บริการ resource server ตรวจสอบ token นี้ ถ้าถูกต้อง จะคืนทรัพยากรที่ร้องขอ

มาสร้าง API Resource เพื่อเป็นตัวแทนของบริการแบ็กเอนด์ของเรากันเถอะ

ไปที่ Logto Console

1. คลิกที่ "API resources" ปุ่มด้านขวา
2. คลิก "Create API resource" เลือก Express ในป๊อปอัพ
3. เติม "DocuMind API" เป็นชื่อ API ใช้ "https://api.documind.com" เป็นตัวระบุตัว API
4. คลิกสร้าง

ไม่ต้องกังวลเกี่ยวกับ URL ตัวระบุตัว API นี้ มันเป็นเพียงตัวระบุตัวที่ไม่ซ้ำสำหรับ API ของคุณใน Logto ซึ่งไม่เกี่ยวกับ URL ปกติของบริการแบ็กเอนด์ของคุณ

คุณจะเห็นการแนะนำวิธีการใช้ API resource คุณสามารถทำตามการแนะนำหรือตามขั้นตอนของเราด้านล่าง

มาสร้าง middleware ชื่อ requireAuth เพื่อป้องกันจุดเข้า POST /organizations กันเถอะ

ในการใช้ middleware นี้ เราจำเป็นต้องมีตัวแปรแวดล้อมเหล่านี้:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

รับตัวแปรเหล่านี้จากจุดปลาย OpenID Configuration ของ Logto tenant ของคุณ เยี่ยมชม https://<your-tenant-id>.logto.app/oidc/.well-known/openid-configuration คุณจะพบข้อมูลที่จำเป็นใน JSON ที่ได้รับคืน:

ตอนนี้ใช้ middleware requireAuth ในจุดเข้า POST /organizations

นี่จะป้องกันจุดเข้า POST /organizations ของเรา เฉพาะผู้ใช้ที่มี Access token ของ Logto ที่ถูกต้องเท่านั้นที่สามารถเข้าถึงได้

เราสามารถได้รับ token จาก Logto ใน frontend ของเรา ผู้ใช้สามารถสร้างองค์กรผ่าน API ของบริการแบ็กเอนด์ของเราด้วย token นี้ middleware ยังให้ข้อมูล user ID เราด้วย ซึ่งมีประโยชน์เมื่อเพิ่มผู้ใช้ในองค์กร

ในโค้ด frontend ให้ประกาศ resource API นี้ใน Logto config เพิ่มตัวระบุตัวลงในอาเรย์ resources

เช่นเคย ผู้ใช้จำเป็นต้องลงชชใหม่หลังจากที่เราอัปเดต Logto config

ในแดชบอร์ด ได้รับ Logto Access Token เมื่อสร้างองค์กร ใช้ token นี้เข้าถึง API ของบริการแบ็กเอนด์ของเรา

ตอนนี้เราสามารถเข้าถึง API ของบริการแบ็กเอนด์ของ DocuMind ได้อย่างถูกต้องแล้ว

การเรียก Logto Management API#

มาสร้างการสร้างองค์กรด้วย Logto Management API กันเถอะ

คล้ายกับการร้องขอ frontend ไปยังบริการแบ็กเอนด์ service ขอแบ็กเอนด์ไปยัง Logto ต้องการ Access token

ใน Logto เราใช้ Machine-to-Machine authentication สำหรับ Access token ดู Interact with Management API

ไปที่หน้าการใช้งานใน Logto Console สร้าง แอป Machine-to-Machine กำหนดบทบาท "การเข้าถึง Logto Management API" คัดลอก Token endpoint, App ID, และ App Secret เราจะใช้สิ่งเหล่านี้สำหรับ Access token

ตอนนี้เราสามารถได้ Access token ของ Logto Management API ผ่านแอป M2M นี้แล้ว

ใช้ Access token นี้เพื่อเรียก Logto Management API

เราจะใช้ API ของ Management เหล่านี้:

• POST /api/organizations: สร้างองค์กร (ดู: Create organization API reference)
• POST /api/organizations/{id}/users: เพิ่มผู้ใช้ในองค์กร (ดู: Add users to organization API reference)

เราตอนนี้ได้สร้างการสร้างองค์กรผ่าน Logto Management API และยังเพิ่มผู้ใช้เข้าไปในองค์กรได้แล้ว

ลองทดสอบฟีเจอร์นี้ในแดชบอร์ดกัน

และคลิก “สร้างองค์กร”

สร้างสำเร็จ!

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

ใช้งานการควบคุมการเข้าถึงในแอปผู้เช่าหลายรายของคุณ#

ตอนนี้มาดูการควบคุมการเข้าถึงในองค์กรกันเถอะ

เราต้องการบรรลุ:

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

มาดูกันว่าฟีเจอร์เหล่านี้ใช้งานอย่างไร

การใช้ token องค์กรของ Logto#

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

ในแอปพลิเคชัน frontend เราสามารถใช้เมธอด getOrganizationToken ของ Logto เพื่อรับโทเค็นสำหรับการเข้าถึงองค์กรที่เฉพาะเจาะจง

ที่นี่ organizationId เป็น id ขององค์กรที่ผู้ใช้สังกัด

ก่อนที่จะใช้ getOrganization หรือฟีเจอร์องค์กรใด ๆ เราต้องรับรองว่า urn:logto:scope:organizations และ urn:logto:resource:organization ได้รวมอยู่ใน Logto config แล้ว เพราะเราได้ประกาศสิ่งเหล่านี้แล้ว เราจะไม่ทวนซ้ำ

ในหน้าขององค์กรของเรา เราใช้ token ขององค์กรเพื่อดึงเอกสารภายในองค์กร

มีสองจุดสำคัญที่ควรทราบใน implementation นี้:

1. ถ้า organizationId ที่ส่งไปยัง getOrganizationToken ไม่ใช่ id ขององค์กรที่สังกัดอยู่ในปัจจุบันสำหรับผู้ใช้ เมธอดนี้จะไม่สามารถรับ token ได้ ทำให้มั่นใจว่าผู้ใช้สามารถเข้าถึงองค์กรของตนเองเท่านั้น
2. เมื่อร้องขอทรัพยากรขององค์กร เราใช้ token ขององค์กรแทน Access token เพราะสำหรับทรัพยากรที่เป็นขององค์กร เราต้องการใช้การควบคุมสิทธิ์องค์กรมากกว่าการควบคุมสิทธิ์ผู้ใช้ (คุณจะเข้าใจดีกว่าเมื่อเราสร้าง GET /documents API ในภายหลัง)

ต่อไป มาสร้าง API GET /documents ในบริการแบ็กเอนด์ของเรา คล้ายกับการ ใช้ API resource เพื่อป้องกัน POST /organizations API เราใช้ตัวระบุตัว resource เฉพาะ องค์กรเพื่อป้องกัน GET /documents API

ก่อนอื่น มาสร้าง middleware ชื่อ requireOrganizationAccess เพื่อป้องกัน ทรัพยากรขององค์กร

จากนั้นเราใช้ middleware requireOrganizationAccess เพื่อป้องกัน API GET /documents

ด้วยวิธีนี้ เราได้สร้างการใช้ organization token เพื่อเข้าถึงทรัพยากรขององค์กร ในบริการแบ็กเอนด์ คุณสามารถดึงทรัพยากรที่ตรงกับจากฐานข้อมูลตาม organization id ได้

บางซอฟต์แวร์ต้องการการแยกข้อมูลระหว่างองค์กร สำหรับการสนทนาและการใช้งานเพิ่มเติม คุณสามารถอ้างอิงบทความบล็อก: Multi-tenancy implementation with PostgreSQL: เรียนรู้ผ่านตัวอย่างจริง

ใช้งานการออกแบบ RBAC ระดับองค์กร#

เราได้สร้างการใช้ organization token เพื่อเข้าถึงทรัพยากรขององค์กรแล้ว ต่อไปเราจะสร้างการควบคุมสิทธิ์ผู้ใช้ในองค์กรโดยใช้ RBAC

สมมติว่า DocuMind มีสองบทบาท: Admin และ Collaborator

Admin สามารถสร้างและเข้าถึงเอกสารได้ ขณะที่ Collaborator สามารถเข้าถึงเอกสารเท่านั้น

ดังนั้นองค์กรของเราจำเป็นต้องมีบทบาทสองประการนี้: Admin และ Collaborator

Admin มีทั้ง read:documents และ create:documents ทำให้ Collaborator มีเพียง read:documents

• Admin
  • read:documents
  • create:documents
• Collaborator
  • read:documents

นี่คือที่ที่ฟีเจอร์เทมเพลตองค์กรของ Logto มีประโยชน์

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

ทำไมต้องเป็นเทมเพลตองค์กร?

เพราะความสามารถในการขยายเป็นหนึ่งในข้อกำหนดที่สำคัญที่สุดของผลิตภัณฑ์ SaaS ในทางกลับกัน สิ่งที่ทำงานสำหรับลูกค้าหนึ่งควรทำงานสำหรับทุกลูกค้า

ไปที่ Logto Console > เทมเพลตองค์กร > สิทธิ์องค์กร และสร้างสิทธิ์สองข้อนั้น: read:documents และ create:documents

จากนั้นไปที่แท็บบทบาทองค์กรที่ใช้งานเพื่อสร้างบทบาทผู้ใช้สองบทบาท: Admin และ Collaborator และกำหนดสิทธิ์ที่ตรงกับบทบาทเหล่านั้น

ด้วยวิธีนี้ เราได้สร้างรูปแบบสิทธิ์ RBAC สำหรับแต่ละองค์กรแล้ว

ต่อไปไปที่หน้ารายละเอียดขององค์กรของเราที่จะกำหนดบทบาทที่เหมาะสมให้กับสมาชิกของเรา

ตอนนี้ผู้ใช้ในองค์กรของเรามีบทบาทแล้ว! คุณสามารถทำตามขั้นตอนเหล่านี้ได้ผ่าน Logto Management API:

ตอนนี้เราสามารถใช้งานการควบคุมสิทธิ์ผู้ใช้ได้โดยการตรวจสอบสิทธิ์ของพวกเขา

ในโค้ดของเรา เราต้องทำให้ token ของผู้ใช้องค์กรบรรทุกข้อมูลสิทธิ์, และตรวจสอบสิทธิ์เหล่านี้ในฝ่ายหลัง

ใน Logto config ของโค้ด frontend เราจะต้องประกาศสิทธิ์ที่ผู้ใช้ต้องการร้องขอภายในองค์กร ลองเพิ่มสิทธิ์ read:documents และ create:documents ลงใน scopes

เหมือนปกติ ล็อกอินอีกครั้งด้วยผู้ใช้ของคุณเพื่อให้ Config เหล่านี้มีผลบังคับใช้

ต่อไป ใน middleware ของฝ่ายปลายหลัง "requireOrganizationAccess" เราเพิ่มการตรวจสอบสิทธิ์ผู้ใช้

จากนั้นสร้าง API POST /documents และใช้ middleware "requireOrganizationAccess" พร้อมการตั้งค่า requiredScopes เพื่อป้องกัน API นี้และ API GET /documents ก่อนหน้านี้

ด้วยวิธีนี้เราได้ตรวจสอบการควบคุมสิทธิ์ผู้ใช้โดยการตรวจสอบสิทธิ์ของพวกเขา

ใน Frontend คุณสามารถดึงข้อมูลสิทธิ์ผู้ใช้โดยการถอดรหัส token ขององค์กรหรือเรียกใช้เมธอด "getOrganizationTokenClaims" ของ Logto

ควบคุมองค์ประกอบของหน้าตามสิทธิ์ของผู้ใช้โดยการตรวจสอบ scopes ใน claims

เพิ่มฟีเจอร์แอปพลิเคชันผู้เช่าหลายรายเพิ่มเติม#

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

ทั้งหมดนี้เป็นฟีเจอร์ที่มีให้ใช้แบบ out-of-the-box และคุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์เหล่านี้ได้ในเอกสาร Logto

สรุป#

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

แต่ดูที่เราทำสำเร็จได้:

• ระบบการรับรองที่สมบูรณ์พร้อมตัวเลือกการเข้าสู่ระบบหลายตัวและการสนับสนุน MFA
• ระบบองค์กรที่ยืดหยุ่นที่รองรับสมาชิกหลายสมาชิก
• การควบคุมการเข้าถึงตามบทบาทภายในองค์กร

และสิ่งที่ดีที่สุด? เราไม่ต้องประดิษฐ์วงล้อใหม่เลย โดยการใช้เครื่องมือสมัยใหม่อย่าง Logto เราเปลี่ยนสิ่งที่น่าจะเป็นการพัฒนาหลายเดือนให้กลายเป็นเรื่องของไม่กี่ชั่วโมง

ซอร์สโค้ดทั้งหมดของบทเรียนนี้มีให้ที่: ตัวอย่าง Multi-tenant SaaS

นี่คือพลังของการพัฒนาสมัยใหม่ในปี 2025 - เราสามารถมุ่งเน้นในการสร้างฟีเจอร์ผลิตภัณฑ์ที่ไม่ซ้ำใครแทนที่จะต่อสู้กับโครงสร้างพื้นฐาน ตอนนี้เป็นเวลาของคุณในการสร้างสิ่งที่น่าทึ่ง!

สำรวจฟีเจอร์ทั้งหมดของ Logto ตั้งแต่ Logto Cloud ไปถึง Logto OSS บน เว็บไซต์ Logto หรือลงทะเบียน Logto cloud วันนี้