รวมระบบระบุตัวตน: แอปแรกและแอปของบุคคลที่สามด้วย Logto
ค้นพบแนวคิดสำคัญและกรณีการใช้งานทั่วไปสำหรับการรวมแอปทั้งแอปแรกและแอปของบุคคลที่สามโดยใช้ Logto เป็นผู้ให้บริการระบุตัวตนของคุณ
สวัสดีครับ เหล่าเทคโนโลยีและมืออาชีพ! ความคิดเห็นของคุณเป็นปัจจัยสำคัญ และเรารู้สึกตื่นเต้นที่จะประกาศการพัฒนาสำคัญ: Logto กำลังก้าวไปเป็นผู้ให้บริการระบุตัวตน (IdP) ของคุณ ในการอัปเดตครั้งถัดไป เราจะเปิดตัว Logto เป็น OpenID Connect (OIDC) IdP เสริมด้วย Consent Page ที่พร้อมใช้งาน
ในขณะที่เราเตรียมปล่อยคุณสมบัติที่สำคัญนี้ เป็นโอกาสที่ดีที่จะสำรวจแนวคิดและโซลู ชั่นที่จำเป็นในด้านระบบระบุตัวตน นี่เป็นเรื่องที่สำคัญเมื่อพิจารณาการรวมและปฏิสัมพันธ์ของแอปพลิเคชันและบริการต่างๆ ในโครงสร้างพื้นฐานดิจิทัลของคุณ
แนวคิด
ในระบบนิเวศของการระบุตัวตน ทุกแอปพลิเคชันหรือทรัพยากรมีบทบาทที่เฉพาะเจาะจง พวกเขาอาจเป็นแอปแรก แอปของบุคคลที่สาม ผู้ให้บริการระบุตัวตน (IdP) ฝ่ายที่อาศัยอยู่ (RP) หรือผู้ให้บริการ (SP) มาสำรวจความสัมพันธ์เหล่านี้กัน
แอปแรก:
แอปเหล่านี้ได้รับการพัฒนาและจัดการโดยผู้ให้บริการระบุตัวตนเอง เพิ่มความปลอดภัยและความน่าเชื่อถือ พวกเขามอบประสบการณ์การลงชื่อเข้าใช้แบบรวมภายในโดเมนเดียวกัน โดยใช้ข้อมูลผู้ใช้ที่สอดคล้องกัน อ่าน “สร้างผลิตภัณฑ์หลายแอป” เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการลงชื่อเข้าใช้แบบโอมินของ Logto
แอปของบุคคลที่สาม:
บริการภายนอกหรือพันธมิตรที่ไม่ได้ร่วมเป็นพันธมิตรกันโดยตรงกับผู้ให้บริการระบุตัวตน (IdP) ถือเป็นแอปของบุคคลที่สาม ทำหน้าที่เป็นฝ่ายที่อาศัยในบริบทของ OIDC หรือผู้ให้บริการในบริบทของ SAML แอปเหล่านี้รวมกับ IdP ผ่านโปรโตคอลต่างๆ เช่น OAuth, OIDC และ SAML ช่วยให้การลงชื่อเข้าใช้และการอนุญาตของผู้ใช้ผ่านบัญชีของ IdP แม้ว่าแอปแรกที่หน้าความเห็นชอบอาจถูกรวมเข้าด้วยกัน สำหรับแอปของบุคคลที่สาม ขั้นตอนนี้เป็นสิ่งสำคัญในกระบวนการยืนยันตัวตน เพื่อให้ผู้ใช้ยินยอมการเข้าถึงข้อมูล
กรณีการใช้งาน
ด้วย Logto คุณกลายเป็นเจ้านายของจักรว าลระบุตัวตนของคุณเอง คุณสามารถสร้างแอปแรกได้มากมายเพื่อประสบการณ์ของผู้ใช้ที่ไม่สะดุด และจำนวนแอปของบุคคลที่สามไม่จำกัดสำหรับความร่วมมือภายนอก Logto ช่วยให้บริการของคุณกลายเป็น IdP ที่หลากหลาย จัดการตัวตนทั้งภายในและภายนอกด้วยความปลอดภัยที่สูงสุด นี่คือตัวอย่างการศึกษาเพื่อแรงบันดาลใจ:
กรณีที่ 1: บริการ B2C กับการรวมตัวตนโซเชียล
คิดถึงบริการของคุณในฐานะผู้ให้บริการ B2C คล้ายกับวิธีที่ Meta ทำหน้าที่เป็น IdP
- การรวมแอปพลิเคชันภายใน: ใช้ระบบบัญชีของ Meta เป็น IdP แพลตฟอร์มเช่น Facebook, Messenger และ Instagram ทำหน้าที่เป็นแอปแรก
- การพัฒนาแอปพลิเคชันของบุคคลที่สาม: ภายในระบบ Meta นักพัฒ นาสามารถสร้างแอปของบุคคลที่สามพร้อมคุณสมบัติการลงชื่อเข้าใช้ด้วย Facebook อนุญาตการเข้าถึงโปรไฟล์ผู้ใช้ระหว่างกระบวนการยืนยันตัวตน
กรณีที่ 2: บริการ B2B กับการควบคุมการเข้าถึงที่เพิ่มขึ้น
จินตนาการถึงบริการของคุณที่ดำเนินการในสภาพแวดล้อม B2B คล้ายกับวิธีที่ GitHub ทำหน้าที่เป็น IdP
- การรวมแอปพลิเคชันภายใน: ใช้ระบบบัญชีของ GitHub เป็น IdP แอปพลิเคชันเช่น GitHub Desktop, GitHub Mobile และ Copilot เป็นตัวอย่างของแอปแรกภายในระบบนี้
- การพัฒนาแอปของบุคคลที่สาม: นักพัฒนามีตัวเลือกในการ "ลงทะเบียนแอพ OAuth ใหม่" ในหน้าตั้งค่านักพัฒนาของ GitHub ทำให้อินทิเกรชั่นของตัวเลือกการลงชื่อเข้าใช้ด้วย GitHub ในหน้าลงชื่อเข้าใช้ของแอปของบุคคลที่สาม สามารถร้องขอการยืนยันตัวตนของผู้ใช้ การเข้าถึงโปรไฟล์ผู้ใช้ และสิทธิ์เฉพาะองค์กร ซึ่งสามารถได้รับการอนุมัติจากสมาชิกหรือผู้ดูแลขององค์กร
- การทำงานอัตโนมัติในแพลตฟอร์มเปิด: นอกจากการเสนอทางเลือกการลงชื่อเข้าใช้โซเชียลแล้ว GitHub ในฐานะ IdP ยังสามารถเพิ่มการทำงานอัตโนมัติในแพลตฟอร์มต่างๆ เช่น Slack สำหรับการรวมแอปของ GitHub ในพื้นที่ทำงานของ Slack GitHub ทำหน้าที่เป็น IdP และ Slack เป็นฝ่ายที่อาศัยอยู่ การกำหนดค่านี้ต้องการให้ผู้ใช้ยืนยันตัวตนผ่าน GitHub เพื่อให้แอป Slack สามารถรับสิทธิ์และข้อมูลที่จำเป็น การเชื่อมต่อดังกล่าวทำให้สามารถใช้คำสั่งเช่น
/github subscribe owner/repo
และ/github subscribe org/repo commits:myBranch
เพื่อปรับปรุงการโต้ตอบและกระบวนการระหว่าง GitHub และ Slack