SSO และ SAML มักถูกใช้แบบคลุมเครือและสามารถตีความได้หลายวิธี ในบทความนี้ เราจะชี้แจงแนวคิดเหล่านี้ อธิบายว่าพวกเขาเกี่ยวข้องกันอย่างไร และให้ตัวอย่างจริงเพื่อให้เข้าใจง่ายขึ้น
SSO และ SAML มักถูกใช้แบบคลุมเครือและสามารถตีความได้หลายวิธี ในบทความนี้ เราจะชี้แจงแนวคิดเหล่านี้ อธิบายว่าพวกเขาเกี่ยวข้องกันอย่างไร และให้ตัวอย่างจริงเพื่อให้เข้าใจง่ายขึ้น
SSO (Single Sign-On) เป็นกระบวนการยืนยันตัวตนที่ให้ผู้ใช้ล็อกอินเพียงครั้งเดียวและเข้าถึงแอปพลิเคชันหรือบริการหลายอย่างโดยไม่ต้องล็อกอินใหม่ทุกครั้ง อย่างไรก็ตาม คำจำกัดความทั่วไปนี้สามารถนำไปใช้กับสถานการณ์ต่างๆ ได้เมื่อมีการใช้ SSO
มีสถานการณ์ต่าง ๆ ที่ SSO เข้ามามีบทบาท
บางครั้ง คนพูดถึง social login เป็น social SSO ตัวอย่างเช่น ผู้ใช้สามารถใช้การล็อกอินของ Google เพื่อสร้างบัญชีในแอปใหม่โดยตรง โดยใช้ข้อมูลและตัวตนที่เก็บไว้ใน Google ในสถานการณ์นี้ ผู้ใช้จัดการตัวตนของตนเอง
Social SSO ทำให้ผู้ใช้ควบคุมข้อมูลได้ง่ายขึ้น ลดขั้นตอนที่ซับซ้อนในกระบวนการสร้างบัญชีและการล็อกอิน Social SSO โดยทั่วไปอาศัยโปรโตคอลมาตรฐานเปิดเช่น OAuth 2.0 และ OIDC
ก่อนอื่น มาทำความเข้าใจแนวคิดของ Identity Provider และ Service Provider กันก่อน
ในแง่เรียบง่าย Identity Provider พิสูจน์ว่าคุณคือใคร และ Service Provider ให้สิทธิ์คุณเข้าถึงบริการของพวกเขาหลังจากที่ยืนยันตัวตนของคุณแล้ว
Enterprise SSO ถูกใช้ในสถานการณ์ที่มุ่งเน้นธุรกิจมากขึ้นและแบ่งออกเป็นสองกรณีที่อธิบายไว้ด้านบน มีสองกรณีทั่วไป: IdP-initiated SSO และ SP-initiated SSO แม้ว่าคำนี้อาจฟังดูทางเทคนิค แต่สถานการณ์ก็ค่อนข้างตรงไปตรงมา
ลองคิดถึงเวลาที่คุณ ในฐานะพนักงาน เข้าร่วมใช้งานแอปพลิเคชันและทรัพยากรของบริษัทของคุณ ปกติแล้ว HR จะสร้างบัญชีให้คุณ จากนั้นคุณจะใช้บัญชีนั้นเพื่อเข้าสู่แพลตฟอร์มเช่น Okta หรือ Google Workspace เมื่อเข้าสู่ระบบ คุณจะไปที่พอร์ทัลขององค์กร ซึ่งคุณสามารถเข้าถึงแอปพลิเคชันทั้งหมดของบริษัท เช่น ระบบเงินเดือน, เครื่องมือการทำงานร่วมกัน, Workday และอื่น ๆ
ลองมองจากอีกมุมหนึ่ง บางครั้งคุณต้องเริ่มที่หน้าเข้าสู่ระบบของผลิตภัณฑ์เฉพาะ ตัวอย่างเช่น หากคุณต้องการใช้ Zoom เพื่อประชุมออนไลน์กับเพื่อนร่วมงานของคุณ คุณจะเห็นตัวเลือก "ล็อกอินด้วย SSO" สถานการณ์นี้เรียกว่า SP-initiated SSO
ข้อดีแรกของ enterprise SSO คือมันช่วยให้ธุรกิจจัดการตัวตนของพนักงานได้ง่าย ยืดหยุ่น และปลอดภัย
ลองนึกดูว่าคุณบริหารบริษัท และพนักงานทุกคนจำเป็นต้องเข้าถึงผลิตภัณฑ์และบริการที่คุณซื้อ เนื่องจากทรัพยากรที่สร้างโดยบริษัทเป็นของบริษัท ควรจะมีระบบตัวตนที่บริษัทเป็นเจ้าของ หากพนักงานใช้ตัวตนส่วนตัวในการเข้าถึงทรัพยากรของบริษัท จะทำให้เกิดปัญหาด้านความปลอดภัยและการจัดการ
อีกด้านหนึ่ง ในสถานการณ์เช่น SP-initiated SSO พนักงานเข้าถึงแอปพลิเคชันและบริการหลายอย่างที่บริษัทเป็นเจ้าของ เมื่อพนักงานเริ่มทำงานหรือออกจากงาน HR ต้องสร้างและลบหลายบัญชีทั่วผลิตภัณฑ์และบริการของบริษัท ซึ่งน่าเบื่อหน่ายและใช้เวลานาน
Enterprise SSO ทำให้กระบวนการนี้ง่ายขึ้นผ่านระบบตัวตนสากล และเครื่องมืออย่าง SCIM (System for Cross-domain Identity Management) และ Just-in-Time provisioning ทำให้มีประสิทธิภาพมากยิ่งขึ้น
สำหรับ IdP-initiated SSO มันมีประโยชน์สำหรับนักพัฒนาผลิตภัณฑ์ที่ต้องการเตรียมตัวให้ "พร้อมสำหรับองค์กร" ตัวอย่างเช่น หากคุณเป็นสตาร์ทอัพที่เริ่มต้นโดยมุ่งเป้าไปที่ผู้บริโภครายบุคคล และต่อมามีองค์กรขนาดใหญ่ต้องการใช้ผลิตภัณฑ์ของคุณ พวกเขาอาจต้องการให้พนักงานล็อกอินโดยใช้ Microsoft Entra ตัวอย่างเช่น ในกรณีนี้ คุณจะต้องรวม enterprise SSO เข้ากับผลิตภัณฑ์ของคุณเพื่อปิดดีล
SAML (Security Assertion Markup Language) เป็นโปรโตคอลมาตรฐานเปิดที่ใช้สำหรับการยืนยันตัวตนและการให้สิทธิ์ พร้อมกับ OAuth และ OIDC SAML ถูกใช้กันอย่างแพร่หลายในระบบการจัดการตัวตน โดยเฉพาะในการจัดการตัวตนพนักงาน ผู้ให้บริการตัวตนเพื่อการพาณิชย์เช่น Okta และ Microsoft Entra มักรองรับ SAML เป็นหนึ่งในโปรโตคอลมาตรฐานของพวกเขา
บางระบบเก่าและผู้ให้บริการลงชื่อเข้าด้วยบัญชีโซเชียลก็มีการรองรับ SAML ด้วย ดังนั้นการมี SAML สร้างอยู่ในระบบของคุณจึงช่วยให้มั่นใจได้ถึงความเข้ากันได้กับผู้ให้บริการตัวตนที่หลากหลายและการเติบโตของระบบในอนาคต
SAML มักถูกใช้ในสถานการณ์ Enterprise SSO ตัวอย่างเช่น ลองพิจารณาสถานการณ์นี้
ทีมขายของคุณติดต่อกับนักพัฒนาผลิตภัณฑ์และกล่าวว่า "เรามีลูกค้ารายใหญ่และพวกเขาต้องการการลงชื่อเข้าใช้ด้วย SAML เราต้องรองรับเทคโนโลยีนี้ด้วย"
สำหรับวิศวกรที่ไม่คุ้นเคยกับ SAML หรือ IAM (Identity and Access Management) ขั้นตอนแรกของพวกเขาน่าจะเป็นการค้นหา "SAML" หรือ "SAML sign-in"
เป้าหมายในที่สุดคือการรวม enterprise SSO เข้ากับผลิตภัณฑ์ของคุณ เพื่อให้มัน "พร้อมสำหรับองค์กร" เพื่อตอบสนองความต้องการของลูกค้ารายใหญ่ที่พึ่งพาเทคโนโลยีอย่าง SAML สำหรับการยืนยันตัวตนที่ปลอดภัย
นี่คือการแบ่งแยกสองประเภทอย่างง่าย
หากต้องการดูว่า SAML ทำงานอย่างไรจากมุมมองทางเทคนิค ตรวจสอบที่ SAML ทำงานอย่างไร
ข้อแตกต่างระหว่างคำจำกัดความของ SAML และ SSO มักจะถูกผสมกัน แต่นี่คือการแบ่งแยกง่าย ๆ
ลองนึกภาพนี้: คุณเดินเข้าไปที่สำนักงานของคุณในตอนเช้า และแทนที่จะต้องล็อกอินเข้าแอปพลิเคชันแต่ละอันแยกกัน — อีเมล ปฏิทิน เครื่องมือการจัดการโครงการ — คุณเพียงแค่ล็อกอินครั้งเดียวและมีการเข้าถึงทุกอย่าง ประสบการณ์ที่ราบรื่นนี้คือ SSO (Single Sign-On) มันเหมือนกับกุญแจสากลที่เปิดประตูทุกบานไปยังเครื่องมือทำงานของคุณ
แต่ SSO ทำงานอย่างไร?
นี่คือจุดที่ SAML (Security Assertion Markup Language) เข้ามามีบทบาท ลองคิดว่า SAML เป็นผู้ส่งสารที่น่าเชื่อถือระหว่างระบบการล็อกอินของคุณ (เรียกว่า Identity Provider หรือ IdP) และแอปที่คุณต้องการใช้ (เรียกว่า Service Providers หรือ SPs) เมื่อคุณล็อกอินผ่าน SSO SAML จะส่ง "หลักฐาน" ของตัวตนของคุณอย่างปลอดภัยจาก IdP ไปยังแอป ยืนยันว่าคุณคือใคร
ดังนั้นสรุปคือ:
ในขณะที่ SSO ช่วยเพิ่มความสะดวกสบาย SAML รับรองว่าสิ่งต่าง ๆ คงปลอดภัยและเชื่อมโยงกัน ทำให้คุณเข้าถึงทุกอย่างได้โดยไม่ต้องคิดซ้ำสอง
ใช่ นอกจาก SAML แล้ว OIDC ยังเป็นโปรโตคอลอีกหนึ่งที่มักใช้ในสถานการณ์ Enterprise SSO ตัวอย่างเช่น ในตัวเชื่อมต่อองค์กรของ Logto รองรับทั้ง Microsoft Entra (OIDC) และ Microsoft Entra (SAML)
หากคุณขายให้กับลูกค้าองค์กร, ควรพิจารณาสนับสนุน SAML ในเร็ว ๆ นี้ แต่อย่ามุ่งเน้นเพียงการสนับสนุนโปรโตคอล SAML - คิดถึงการไหลของการยืนยันตัวตน Enterprise SSO ทั้งหมด
Logto ให้บริการ enterprise SSO flows และรองรับตัวเชื่อมต่อ SAML ที่มีชื่อเสียงหลายตัว สามารถรวมเข้ากับสถานการณ์ทั่วไปมากมายที่คุณต้องการ สำรวจฟีเจอร์ทั้งหมดของ Logto ตั้งแต่ Logto Cloud ไปจนถึง Logto OSS บน เว็บไซต์ Logto