CIAM 101: การยืนยันตัวตน, เอกลักษณ์, SSO

ภูมิหลัง#

ฉันเริ่มสร้าง Logto เพราะฉันสังเกตว่า Identity and Access Management (IAM) ได้ซับซ้อนและขยายตัวมากขึ้นเมื่อเวลาผ่านไป แนวคิดของ IAM ใหญ่พอที่จะทำให้เกิดแนวคิดใหม่ ๆ เช่น WIAM (Workforce IAM) และ CIAM (Customer IAM)

แม้ว่า WIAM และ CIAM จะมีพื้นฐานเดียวกัน แต่พวกเขามีกรณีการใช้งานที่แตกต่างกัน: WIAM มักจะใช้สำหรับผู้ใช้งานภายใน ในขณะที่ CIAM ใช้สำหรับลูกค้าภายนอก ตัวอย่างบางกรณี:

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

Logto เริ่มต้นด้วย CIAM ด้วยเหตุผลหลากหลาย (เราจะมีบทความอีกชิ้นหนึ่งที่พูดเกี่ยวกับเรื่องนี้) ในระหว่างการพัฒนา เราตระหนักว่าการสร้างความเข้าใจเป็นหนึ่งเดียวกันในทีมจะมีประโยชน์ก่อนที่เราจะนำผลิตภัณฑ์ของเราไปสู่ระดับต่อไป เราหวังว่านี่จะช่วยให้คุณเข้าใจภาพรวมของ IAM ได้ดีขึ้น

เริ่มต้นกันเลย!

พื้นฐานของ CIAM#

ในบทความนี้ เราจะมุ่งเน้นที่แนวคิดพื้นฐานของ CIAM และปัญหาที่เราอาจพบในระหว่างหรือหลังจากการไหลของการยืนยันตัวตน เราจะพูดถึง single sign-on (SSO) และสถานการณ์ที่เกี่ยวข้อง

การยืนยันตัวตนและการอนุญาต#

💡 การยืนยันตัวตนถูกกำหนดตั้งแต่ต้นว่า "คุณคือใคร?" อย่างไรก็ตาม เมื่อพูดถึงเอกลักษณ์ดิจิตอล มันมีความแม่นยำมากขึ้นเมื่อต้องแสดงการยืนยันตัวตนด้วยการ "พิสูจน์ความเป็นเจ้าของเอกลักษณ์" (ขอบคุณ Calm-Card-2424)

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

• ตัวอย่างสำหรับการยืนยันตัวตน
  • การลงชื่อเข้าใช้ด้วยรหัสผ่าน, การลงชื่อเข้าใช้แบบไม่ใช้รหัสผ่าน, การลงชื่อเข้าใช้ผ่านโซเชียล ฯลฯ
  • การยืนยันตัวตนของเครื่องอีกเครื่องหนึ่ง
• ตัวอย่างสำหรับการอนุญาต
  • การควบคุมการเข้าถึงตามบทบาท
  • การควบคุมการเข้าถึงตามคุณลักษณะ
• ตัวอย่างสำหรับข้อยกเว้น
  • ข้อมูลที่ไม่ใช่เอกลักษณ์
  • Web hooks

เอกลักษณ์และผู้เช่า#

เอกลักษณ์มักหมายถึงผู้ใช้หรือเครื่อง เมื่อผ่านการยืนยันตัวตนเรียบร้อยแล้ว จะมีการออก ID Token เป็นเอกลักษณ์

พูดได้อีกอย่างหนึ่ง วัตถุประสงค์หลักของการยืนยันตัวตนคือการได้รับเอกลักษณ์

ผู้เช่าคือกลุ่มของเอกลักษณ์:

เมื่อเราพูดถึง "หลายผู้เช่า" เราหมายถึงหลาย Logto อินสแตนซ์ที่แยกเอกลักษณ์จากกัน ในคำอื่นๆ หลาย Logto อินสแตนซ์

โปรดสังเกตว่ามันมีสองระบบเอกลักษณ์ที่ แยกจากกัน กล่าวคือ คุณไม่สามารถใช้เอกลักษณ์ของ Tenant 1 ใน Tenant 2 ได้ แม้จะใช้ตัวระบุเดียวกัน (อีเมล, โทรศัพท์ ฯลฯ) เหมือนเช่นที่สมาชิก Costco ของคุณใช้ที่ Whole Foods ไม่ได้

แอพและผู้เช่า#

เช่นเดียวกับเอกลักษณ์ แอพก็เป็นส่วนหนึ่งของผู้เช่าด้วย มีหลายสิ่งที่ควรจำ:

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

ผู้ให้บริการเอกลักษณ์ (IdP) และผู้ให้บริการ (SP)#

ความแตกต่างระหว่างผู้ให้บริการสองประเภทนี้ค่อนข้างซับซ้อนแต่สำคัญ

• Identity Provider คือบริการที่ให้การยืนยันตัวตน (AuthN) และออกเอกลักษณ์

คุณสามารถหาอธิบายต่าง ๆ เกี่ยวกับผู้ให้บริการจาก Google ถึงแม้ว่ามันอาจจะไม่พอใจเท่าไหร่ ในความคิดของฉัน ผู้ให้บริการคือแนวคิดสัมพัทธ์:

• Service Provider (หรือ ร่วมมือใน OIDC) คือบริการหรือไคลเอนต์ที่เริ่มต้นการยืนยันตัวตน (AuthN) และขอผลลัพธ์จาก Identity Providers

คำถามทดสอบ#

พิจารณาสถานการณ์การลงชื่อเข้าใช้ผ่านโซเชียลทั่วไป:

❓ กี่ผู้ให้บริการและผู้ให้บริการในแผนภาพนี้?

คำตอบ

ทั้งคู่มีสอง iOS App เป็นผู้ให้บริการให้กับ Logto ในขณะที่ Logto เป็นผู้ให้บริการระบุ Logto เป็น ผู้ให้บริการให้กับ GitHub ในขณะที่ GitHub เป็นผู้ให้บริการเอกลักษณ์ ดังนั้น Logto เป็นผู้ให้บริการ และเป็นผู้ให้บริการเอกลักษณ์.

กรณีศึกษา: บริษัทโซลูชั่นเทคโนโลยี#

คุณเป็น CTO ของบริษัทโซลูชั่นเทคโนโลยี คุณมีคู่ค้าธุรกิจกว่า 100 รายและคุณได้ส่งมอบโครงการกว่า 300 โครงการ

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

❓ Logto (หรือ CIAM product) จะช่วยได้อย่างไร?

คำตอบ

สร้าง Logto instance สำหรับแต่ละคู่ค้าธุรกิจ แต่ละคู่ค้าถือเป็นผู้เช่า โครงการถูกแมพกับ "Apps" ใน Logto

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

เราพูดถึงอะไรเมื่อเราพูดถึง SSO#

เราพบว่าคำว่า “SSO” มักก่อให้เกิดความสับสน เราพิจารณา single sign-on(SSO) เป็นพฤติกรรม ไม่ใช่แนวคิดธุรกิจ ดังนั้น SSO จึงไม่เท่ากับ "SSO ใน WIAM"

เมื่อเราพูดว่า "มันต้องการ SSO" มันสามารถหมายถึงหนึ่งในกรณีต่อไปนี้:

SSO Case 1#

👉🏽 ในบริษัทใหญ่ พนักงานใช้ข้อมูลเข้าสู่ระบบเดียวกันสำหรับทรัพยากรทั้งหมดที่มีใบอนุญาตของบริษัท (เช่น อีเมล, IM, บริการคลาวด์)

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

SSO Case 2#

👉🏽 ผู้ใช้งานสุดท้ายใช้ข้อมูลเข้าสู่ระบบเดียวกันสำหรับทุกบริการที่พัฒนาโดยบริษัทเดียวกัน (เช่น GSuite)

Logto กำลังมุ่งเน้นวิธีการที่อธิบายไว้ข้างต้นนี้ ในขณะนี้อาจมีผู้ให้บริการเอกลักษณ์ภายนอกหลายราย เช่น โซเชียลซ้อคุณภาพสภา (no dataset csrmerasia) Logto ยังคงเป็นแหล่งความจริงสำหรับเอกลักษณ์เพียงใช้ "ยืม" พวกเขามาจากผู้ให้บริการอื่น ในกรณีนี้ Logto ก็เป็นผู้ให้บริการเอกลักษณ์ (ต่อแอพ GSuite) และเป็นผู้ให้บริการ (ต่อผู้ให้บริการเอกลักษณ์ภายนอก)

SSO Case 3#

👉🏽 ผู้ใช้งานสุดท้ายสามารถใช้ผู้ให้บริการเอกลักษณ์ที่เฉพาะเจาะจงกับโดเมนอีเมลที่กำหนดเพื่อทำการตรวจสอบเอกลักษณ์ได้ ตัวอย่างเช่น, การลงชื่อเข้าสู่ Figma ด้วย Google Workspace.

นี่คือกรณีการใช้ SSO ใน CIAM ที่พบมากที่สุด มาดูใกล้ชิดกันหน่อย

ถ้าเราต้องการลงชื่อเข้าใช้ Figma โดยใช้อีเมล @silverhand.io ของเรา เราสามารถเลือกใช้การลงชื่อผ่านโซเชียลหรือ SSO ก็ได้ ตัวเลขด้านล่างแสดงความแตกต่างระหว่างสองวิธี:

ในคำพูด:

• หลังจากลงชื่อเข้าใช้ผ่านโซเชียล ผู้ใช้สามารถตั้งรหัสผ่านหรือเปลี่ยนอีเมลใน Figma ได้อย่างอิสระ
• หลังจาก SSO ผู้ใช้ไม่สามารถตั้งรหัสผ่านหรือเปลี่ยนข้อมูลส่วนตัวใด ๆ รวมถึงอีเมลได้ เนื่องจากเอกลักษณ์ของพวกเขาถูกจัดการโดย Google Workspace

ในกรณีนี้ Logto เป็นทั้งผู้ให้บริการเอกลักษณ์และผู้ให้บริการ ปรากฏว่า SSO ซับซ้อนกว่ากระบวนการลงชื่อเข้าใช้ปกติ ประโยชน์สำหรับเจ้าของเอกลักษณ์คืออะไร?

• การควบคุมแบบรวมศูนย์: เก็บข้อมูลเอกลักษณ์และกระบวนการยืนยันตัวตนในที่เดียว และตรวจสอบให้มั่นใจว่าข้อมูลผู้ใช้อยู่ในสภาพใหม่อยู่เสมอ ไม่จำเป็นต้องเพิ่มหรือลบใบอนุญาตข้ามแอพต่าง ๆ สำหรับการเปลี่ยนแปลง
• ปรับปรุงประสบการณ์ผู้ใช้: เจ้าของเอกลักษณ์ที่ต้องการ SSO มักเป็นบริษัท พนักงานของพวกเขาสามารถใช้ข้อมูลเข้าเดียวกันและเซสชันร่วมกันสำหรับการใช้งานข้ามบริษัท เช่น Figma, Zoom, Slack, ฯลฯ
• เพิ่มความปลอดภัย: คุณอาจได้สังเกตว่าบางบริษัทต้องการวิธีการลงชื่อเข้าใช้ที่เฉพาะเจาะจง เช่น รหัสยืนยันแบบไดนามิก การใช้ SSO สามารถประกันได้ว่าพนักงานทุกคนใช้วิธีการลงชื่อเข้าเข้าเดียวกันสำหรับการเข้าถึงทรัพยากรทั้งหมด

🤔 ฉลาดเหมือนคุณต้องสังเกตว่านี่คือ SSO Case 1 จากมุมมองของ SaaS จริงๆ

ได้เวลาพูดคุยเกี่ยวกับ "X" ในกราฟ SSO แล้ว นี่แสดงถึงกระบวนการที่ Figma เชื่อมต่อโดเมนอีเมลกับผู้ให้บริการเอกลักษณ์เฉพาะ แต่มันทำงานอย่างไร?

การแมพ SSO#

เพราะการร้องขอส่วนใหญ่มาจากลูกค้าบริษัท เราจึงเรียกกระบวนการ "SSO Case 3" จากส่วนที่ผ่านมาเป็น "Enterprise SSO" เพื่อความชัดเจน

เราสามารถคิดแนวทางแก้ปัญหาง่าย ๆ ได้: สร้างการแมพระหว่างโดเมนอีเมลและวิธี SSO แล้วอัปเดตมันด้วยมือ

การดำเนินการของกระบวนการ “X” ตอนนี้ชัดเจน:

🔍 ค้นหาวิธี Enterprise SSO ที่แมพของโดเมนอีเมลที่ให้มา

ดังนั้นหากคุณกำหนดค่า silverhand.io เป็นโดเมนอีเมลที่ถูกต้องที่เชื่อมต่อกับ URL SSO ของ Google Workspace ผู้ใช้ที่พยายามลงชื่อเข้าด้วยอีเมล @silverhand.io จะถูกเปลี่ยนไปที่หน้าลงชื่อของ Google Workspace แทนที่จะถูกประมวลผลในที่

เมื่อคุณมีลูกค้าบริษัทไม่กี่โหลที่ต้องการ Enterprise SSO การจัดการการแมพด้วยมือก็โอเค อย่างไรก็ตามยังมีข้อพิจารณาอื่น ๆ อีก:

1. ถ้ามีลูกค้าบริษัทหลายร้อยหรือหลายพัน Enterprise SSO จะทำอย่างไร?
2. อะไรคือความสัมพันธ์ระหว่าง “ผู้ใช้ธรรมดา” และ “ผู้ใช้ Enterprise SSO”?
3. ข้อมูลควรถูกแยกเก็บระหว่างลูกค้า Enterprise SSO ต่าง ๆ หรือไม่?
4. จำเป็นต้องมีแดชบอร์ดให้ผู้ดูแลระบบ Enterprise SSO เพื่อดูผู้ใช้ที่ใช้งาน, บันทึกการตรวจสอบ ฯลฯ หรือไม่?
5. จะสามารถหยุดใช้งานบัญชีโดยอัตโนมัติเมื่อผู้ใช้ถูกลบออกจากผู้ให้บริการเอกลักษณ์ Enterprise SSO ได้อย่างไร?

และอีกมากมาย เนื่องจากเกือบทุก Enterprise SSO อิงกับโดเมนอีเมล เราจึงสามารถคิดแนวทางที่ดีกว่าได้อย่างรวดเร็ว:

• หากผู้ใช้สามารถพิสูจน์ความเป็นเจ้าของโดเมนนั้นได้ พวกเขาจะสามารถตั้งค่า enterprise SSO ของโดเมนนั้นได้ด้วยตัวเอง

วิธีการนี้สามารถตอบคำถามแรกสองข้อ:

1. ถ้ามีลูกค้าบริษัทหลายร้อยหรือหลายพัน Enterprise SSO จะทำอย่างไร?

• พวกเขาสามารถกำหนดค่า Enterprise SSO ด้วยตัวเองได้

2. อะไรคือความสัมพันธ์ระหว่าง “ผู้ใช้ธรรมดา” และ “ผู้ใช้ Enterprise SSO”?

• เราเปิดให้ผู้ใช้ทั่วไปเข้าถึงวิธีการลงชื่อทุกวิธีที่สามารถใช้ได้ยกเว้น Enterprise SSO; ในขณะที่จำกัดวิธีการลงชื่อเฉพาะ Enterprise SSO ในผู้ใช้ที่พยายามลงชื่อเข้าด้วยโดเมนที่กำหนด

สำหรับคำถามที่สาม:

3. ข้อมูลควรถูกแยกเก็บระหว่างลูกค้า Enterprise SSO ต่าง ๆ หรือไม่?

• ใช่และไม่ใช่ ได้เวลาพูดถึงองค์กรแล้ว

องค์กร#

เราได้พูดถึงการใช้โดเมนอีเมลเพื่อจดจำวิธี Enterprise SSO ที่เฉพาะเจาะจงในภาษาอื่น ๆ ประการอื่น ๆ ได้แก่คำถามที่ 4 และ 5 ในส่วนที่ผ่านมา หลายปีที่ผ่านมา เป็นที่ยอมรับว่าเครือบริษัท SaaS ที่โดดเด่นได้พัฒนารูปแบบที่ชำนาญเพื่อรับมือกับปัญหาเหล่านี้: องค์กร

กฎระเบียบองค์กร

1. องค์กรคือกลุ่มเอกลักษณ์ที่มีขนาดเล็กกว่า Tenant
2. องค์กรทั้งหมดเชื่อมโยงกับ Tenant

คุณอาจเห็นคำอื่น ๆ เช่น "พื้นที่ทำงาน", "ทีม" หรือแม้กระทั่ง "เช่า" ในซอฟต์แวร์ เพื่อระบุว่ามันเป็นแนวคิดที่เรากำลังพูดถึงหรือไม่ ตรวจสอบว่ามันแสดงถึง “กลุ่มเอกลักษณ์” หรือไม่

ในบทความนี้ เราจะใช้คำว่า "องค์กร" เพื่อความสม่ำเสมอ

ใน Notion คุณสามารถสร้างและเข้าร่วมพื้นที่ทำงานหลายแห่ง (เช่น องค์กร) ด้วยอีเมลเดียวกันและสลับระหว่างพวกเขาได้ง่าย

สำหรับ Slack ดูเหมือนจะเหมือนกัน แต่เราเชื่อว่ามันใช้เอกลักษณ์ต่างกันเบื้องหลัง เนื่องจากเราต้องสร้างบัญชีใหม่สำหรับพื้นที่ทำงานแต่ละแห่ง

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

แต่ละองค์กรยังมีตัวระบุ โดยทั่วไปเรียกว่า “โดเมนองค์กร”

คำถามทดสอบ#

❓ แอพสามารถสัมพันธ์กับองค์กรได้หรือไม่?

คำตอบ

สามารถ สามารถได้. ตามที่เราได้พูดถึงในตอนต้น แอพสามารถมีเอกลักษณ์ได้ คุณสามารถอธิบายสภาพแวดล้อมทางธุรกิจของกรณีนี้ได้หรือไม่?

คำถามที่เหลืออยู่#

3. ข้อมูลควรถูกแยกเก็บระหว่างลูกค้า Enterprise SSO ต่าง ๆ หรือไม่?

• ใช่: แยกข้อมูลธุรกิจ เช่น ข้อความและเอกสาร ในระดับองค์กร
• ไม่: เก็บเอกลักษณ์เป็นเอกภาพ เนื่องจากพวกเขาไม่จำเป็นต้องสัมพันธ์กับองค์กร
• สังเกตว่ามีนิติบุคคลที่แยกต่างหากสามแห่งที่เกี่ยวข้องที่นี่: เอกลักษณ์, องค์กร, และการตั้งค่า Enterprise SSO; ซึ่งเพิ่มความซับซ้อนอย่างดีเยี่ยม คำถามตัวเองไม่เจาะจงพอ

4. จำเป็นต้องมีแดชบอร์ดให้ผู้ดูแลระบบ Enterprise SSO เพื่อดูผู้ใช้ที่ใช้งาน, บันทึกการตรวจสอบ ฯลฯ หรือไม่?

5. จะสามารถหยุดใช้งานบัญชีโดยอัตโนมัติเมื่อผู้ใช้ถูกลบออกจากผู้ให้บริการเอกลักษณ์ Enterprise SSO ได้อย่างไร?

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

หมายเหตุสิ้นสุด#

เราได้แนะนำหลายแนวคิด: การยืนยันตัวตน (AuthN), การอนุญาต (AuthZ), เอกลักษณ์, ผู้เช่า, แอพพลิเคชัน, ผู้ให้บริการเอกลักษณ์ (IdP), ผู้ให้บริการ (SP), Single sign-on (SSO), และ Enterprise SSO (องค์กร). อาจใช้เวลาสักครู่ในการทำความเข้าใจทั้งหมด

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

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