• OIDC
  • SAML
  • SSO
  • การตรวจสอบสิทธิ์
  • การอนุญาต

SAML เทียบกับ OIDC

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

Simeng
Simeng
Developer

SAML คืออะไร?

SAML (Security Assertion Markup Language) เป็นมาตรฐานเปิดที่ใช้ XML สำหรับแลกเปลี่ยนข้อมูลการตรวจสอบสิทธิ์และการอนุญาตระหว่างคู่สัญญาต่าง ๆ โดยเฉพาะระหว่างผู้ให้บริการระบุตัวตน (IdP) และผู้ให้บริการ (SP) มันช่วยให้สามารถทำ SSO ผ่านเว็บเพื่อให้ผู้ใช้สามารถตรวจสอบสิทธิ์ครั้งเดียวเพื่อเข้าถึงแอปพลิเคชันหลายตัวได้ SAML เป็นโปรโตคอลที่มีมาอย่างยาวนานและได้นำไปใช้อย่างกว้างขวางโดยองค์กรต่าง ๆ บางแพลตฟอร์ม SaaS ที่ได้รับความนิยมมากที่สุดเช่น Salesforce, Workday, และ Microsoft Azure AD ล้วนรองรับ SAML SSO

องค์ประกอบของ SAML

  1. ผู้ให้บริการระบุตัวตน (IdP): นิติบุคคลที่ตรวจสอบสิทธิ์ของผู้ใช้และให้ข้อมูลระบุตัวตนกับผู้ให้บริการ
  2. ผู้ให้บริการ (SP): นิติบุคคลที่ให้บริการผู้ใช้และพึ่งพาผู้ให้บริการระบุตัวตนเพื่อตรวจสอบสิทธิ์ผู้ใช้
  3. คำยืนยัน SAML: เอกสารที่ใช้ XML ที่บรรทุกข้อมูลการตรวจสอบสิทธิ์และการอนุญาตของผู้ใช้ รวมถึงคำประกาศการตรวจสอบสิทธิ์ คำประกาศคุณสมบัติ และคำประกาศการตัดสินใจการอนุญาต
  4. โปรโตคอล SAML: กำหนดรูปแบบการส่งข้อความและกฎสำหรับการแลกเปลี่ยนคำยืนยัน SAML ระหว่าง IdP และ SP
  5. การเชื่อมโยง SAML: กำหนดวิธีการที่ข้อความ SAML ถูกส่งผ่านโปรโตคอลการสื่อสารต่าง ๆ เช่น HTTP POST, HTTP Redirect เป็นต้น
  6. ข้อมูลเมตา SAML: เอกสารที่ใช้ XML ที่มีข้อมูลการกำหนดค่าของ IdP และ SP รวมถึงกุญแจสาธารณะ ชุดปลายทาง และการสนับสนุนการเชื่อมโยงที่ใช้ในการสร้างความเชื่อใจระหว่าง IdP และ SP
  7. ปลายทางการลงชื่อเข้าระบบสัญญาณเดียว: จุดที่ SP ส่งต่อผู้ใช้ไปยังเพื่อตรวจสอบสิทธิ์กับ IdP
  8. URL บริการผู้บริโภคคำยืนยัน (ACS): ปลายทางที่ IdP ส่งคำยืนยัน SAML ไปหลังจากการตรวจสอบสิทธิ์สำเร็จ

SAML ทำงานอย่างไร?

  1. การไหลของ SSO ที่เริ่มโดย SP:
  1. การไหลของ SSO ที่เริ่มโดย IdP:

ข้อดีของ SAML

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

ข้อท้าทายของ SAML

  • ความซับซ้อน: SAML เป็นโปรโตคอลที่ซับซ้อนซึ่งต้องการการเข้าใจอย่างลึกซึ้งของ XML และแนวคิดเรื่องการรักษาความปลอดภัย
  • ประสิทธิภาพ: ข้อความ SAML ใช้ XML และสามารถมีขนาดใหญ่ การส่งและการแยกวิเคราะห์เอกสาร XML อาจช้ากว่าเมื่อเปรียบเทียบกับรูปแบบโทเค็นอย่าง JSON Web Token (JWT)
  • มาตรฐานที่ล้าสมัย: SAML เป็นมาตรฐานที่เก่ากว่าเมื่อเทียบกับ OIDC และถูกมองว่ามีความปลอดภัยน้อยกว่า
  • ล็อคอินผู้ขาย: SAML เป็นโปรโตคอลที่ผู้ขายเจาะจง และการสลับระหว่างผู้ขายอาจเป็นเรื่องท้าทาย

OIDC คืออะไร?

OIDC (OpenID Connect) เป็นเลเยอร์ที่สร้างตัวตนบนโปรโตคอล OAuth 2.0 คล้ายกับ SAML OIDC ยังถูกใช้สำหรับการแลกเปลี่ยนข้อมูลการตรวจสอบสิทธิ์และการอนุญาตระหว่าง IdP และ SP

เมื่อเปรียบเทียบกับ SAML OIDC เป็นโปรโตคอลที่ทันสมัยและเบากว่าซึ่งได้รับความนิยมสำหรับแอปพลิเคชันเว็บและมือถือที่ทันสมัย OIDC ใช้ JWT สำหรับการส่งข้อมูลระบุตัวตน ซึ่งมีขนาดกะทัดรัดและใช้งานง่ายกว่าเมื่อเปรียบเทียบกับคำยืนยัน SAML ที่ใช้ XML เป็นที่นิยมโดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันที่มุ่งหน้าไปที่ผู้บริโภคและความปลอดภัย API

องค์ประกอบของ OIDC

  1. ผู้ให้บริการระบุตัวตน (IdP): นิติบุคคลที่ตรวจสอบสิทธิ์ของผู้ใช้และให้ข้อมูลระบุตัวตนกับผู้ให้บริการ
  2. ฝ่ายที่พึ่งพา (RP): นิติบุคคลที่ให้บริการผู้ใช้และพึ่งพาผู้ให้บริการระบุตัวตนเพื่อตรวจสอบสิทธิ์ผู้ใช้ เช่น แอปพลิเคชันเว็บ แอปพลิเคชันมือถือ หรือ API
  3. โทเค็น OIDC: โทเค็นที่บรรทุกข้อมูลระบุตัวตนของผู้ใช้
    • โทเค็นตัวตน: โทเค็นรูปแบบ JWT ที่มีข้อมูลตัวตนของผู้ใช้
    • โทเค็นการเข้าถึง: โทเค็นรูปแบบ JWT หรือ opaque ที่ให้การเข้าถึงทรัพยากรที่ได้รับการคุ้มครอง
    • โทเค็นการรีเฟรช: โทเค็นที่ใช้เพื่อขอโทเค็นการเข้าถึงใหม่โดยไม่ต้องตรวจสอบสิทธิ์ผู้ใช้อีกครั้ง มันให้การอนุญาตระยะยาวออฟไลน์แก่ RP
  4. ปลายทาง OIDC: ปลายทางที่ใช้สำหรับการตรวจสอบสิทธิ์และแลกเปลี่ยนโทเค็น บางปลายทางที่สำคัญคือ:
    • ปลายทางการค้นพบ: ที่ RP สามารถดึงข้อมูลการกำหนดค่า OIDC สาธารณะจาก IdP
    • ปลายทางการอนุญาต: ที่ RP ส่งข้อขอการตรวจสอบสิทธิ์
    • ปลายทางโทเค็น: ที่ RP ขอโทเค็นจากเซิร์ฟเวอร์การอนุญาต
    • ปลายทางข้อมูลผู้ใช้: ที่ RP สามารถดึงข้อมูลโปรไฟล์ของผู้ใช้
  5. ขอบเขต: OIDC กำหนดชุดของขอบเขตที่เป็นมาตรฐานที่กำหนดสิทธิ์การเข้าถึงที่มอบให้ RP เช่น openid, profile, email, address เป็นต้น

OIDC ทำงานอย่างไร?

OIDC มีหลายการไหลที่ถูกออกแบบมาโดยเฉพาะสำหรับกรณีการใช้งานที่แตกต่างกัน นี่คือการไหลของ OIDC ที่พบมากที่สุดสองแบบ:

  1. การไหลของโค้ดการอนุญาต:

การไหลของโค้ดการอนุญาตเป็นการไหลที่พบมากที่สุดที่ใช้ใน OIDC สำหรับแอปพลิเคชันที่มุ่งหน้าไปที่ผู้บริโภค

  1. การไหลของข้อมูลประจำตัวลูกค้า:

การไหลของข้อมูลประจำตัวลูกค้าสามารถใช้สำหรับการตรวจสอบสิทธิ์ที่ไม่ต้องการผู้ใช้ (การเชื่อมต่อระหว่างเครื่อง)

ข้อดีของ OIDC

  • ทันสมัยและเบา: OIDC เป็นโปรโตคอลที่ทันสมัยที่ใช้โทเค็น JWT ที่ใช้ JSON ซึ่งมีขนาดกะทัดรัดและใช้งานง่ายเมื่อเทียบกับคำยืนยัน SAML ที่ใช้ XML
  • แอปพลิเคชันที่มุ่งหน้าไปที่ผู้บริโภค: OIDC เป็นที่นิยมโดยเฉพาะสำหรับแอปพลิเคชันที่มุ่งหน้าไปที่ผู้บริโภคและความปลอดภัยของ API
  • ความสามารถในการทำงานร่วมกัน: สร้างบนพื้นฐานของ OAuth 2.0 OIDC เข้ากันได้กับแพลตฟอร์ม อุปกรณ์ และแพลตฟอร์มที่หลากหลาย
  • ความปลอดภัย: OIDC ให้วิธีที่ปลอดภัยกว่าสำหรับการตรวจสอบสิทธิ์ของผู้ใช้และการป้องกัน API มันรวมถึงคุณลักษณะด้านความปลอดภัยที่ทันสมัยหลายประการเช่นการตรวจสอบโทเค็น การเพิกถอนโทเค็น Proof Key for Code Exchange (PKCE) และรองรับการไหลของการตรวจสอบสิทธิ์ที่แตกต่างกันเพื่อให้ตอบสนองต่อความต้องการด้านความปลอดภัยต่าง ๆ
  • ง่ายต่อการใช้งาน: OIDC ง่ายต่อการใช้งานและทำงานด้วยเมื่อเปรียบเทียบกับ SAML มันเป็นมิตรกับนักพัฒนามากกว่าและมีไลบรารีและ SDK ที่ครอบคลุมสำหรับหลายภาษาโปรแกรมและแพลตฟอร์ม

ข้อท้าทายของ OIDC

  • การจัดการโทเค็น: OIDC พึ่งพาโทเค็นสำหรับการตรวจสอบสิทธิ์และการอนุญาต ต้องมีการปฏิบัติการจัดการโทเค็นที่เหมาะสมเพื่อให้ปลอดภัย
  • ความซับซ้อน: แม้ว่า OIDC จะง่ายสำหรับการตั้งค่าพื้นฐาน แต่เนื่องจากลักษณะที่ยืดหยุ่น อาจเพิ่มความซับซ้อนเมื่อใช้งานการปรับแต่งขั้นสูง เช่น ข้อเรียกร้องที่กำหนดเอง และ การควบคุมการเข้าถึงตามบทบาท (RBAC) เป็นต้น
  • การยอมรับ: OIDC ยังค่อนข้างใหม่กว่าเมื่อเทียบกับ SAML โดยเฉพาะในพื้นที่องค์กร ระบบเก่าบางอย่างอาจยังคงพึ่งพา SAML สำหรับวัตถุประสงค์ SSO

การเปรียบเทียบ SAML เทียบกับ OIDC

แง่มุมSAMLOIDC
รูปแบบโทเค็นคำยืนยัน SAML ที่ใช้ XMLโทเค็น JWT ที่ใช้ JSON
กรณีการใช้งานหลักSSO ขององค์กร การบูรณาการ B2Bแอปที่มุ่งหน้าไปที่ผู้บริโภค ความปลอดภัย API
ความง่ายในการใช้งานซับซ้อน ต้องมีความเข้าใจใน XML อย่างลึกซึ้งง่าย ใช้ JSON ง่ายต่อการใช้งาน
การยอมรับได้รับการยอมรับอย่างกว้างขวางจากองค์กรได้รับความนิยมมากขึ้นสำหรับแอปสมัยใหม่
ความปลอดภัยมีประสบการณ์แต่ถูกมองว่ามีความปลอดภัยน้อยกว่าทันสมัยและปลอดภัยกว่า
ความยืดหยุ่นจำกัด ออกแบบมาสำหรับกรณีการใช้งาน SSOยืดหยุ่น รองรับหลากหลายกรณีการใช้งาน

อนาคตของ SAML และ OIDC

ทั้ง SAML และ OIDC ใช้กันอย่างกว้างขวางเพื่อจุดประสงค์การตรวจสอบสิทธิ์และการอนุญาต

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

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