SSO เริ่มต้นจาก IdP กับ SSO เริ่มต้นจาก SP
เรียนรู้เพิ่มเติมเกี่ยวกับความแตกต่างระหว่าง SSO เริ่มต้นจาก IdP และ SSO เริ่มต้นจาก SP และทำไม SSO เริ่มต้นจาก SP ถึงมีความปลอดภัยมากกว่า
เรียนรู้เพิ่มเติมเกี่ยวกับความแตกต่างระหว่าง SSO เริ่มต้นจาก IdP และ SSO เริ่มต้นจาก SP และทำไม SSO เริ่มต้นจาก SP ถึงมีความปลอดภัยมากกว่า
ตามชื่อที่บอกไว้, SSO เริ่มต้นจาก SP เริ่มต้นโดยผู้ให้บริการ ผู้ใช้เริ่มกระบวนการยืนยันตัวตนโดยการเข้าถึงทรัพยากรบนเว็บไซต์ของ SP จากนั้น SP จะเปลี่ยนเส้นทางผู้ใช้ไปที่ IdP เพื่อการยืนยันตัวตน เมื่อผู้ใช้ยืนยันตัวตนสำเร็จแล้ว, IdP จะสร้างโทเค็น (OIDC) หรือการยืนยัน SAML (SAML) และส่งกลับไปที่ SP จากนั้น SP จะยืนยันโทเค็นหรือการยืนยันและอนุญาตการเข้าถึงให้ผู้ใช้
ต่างจาก SSO เริ่มต้นจาก SP, SSO เริ่มต้นจาก IdP ทำงานโดยผู้ให้บริการข้อมูลประจำตัว ผู้ใช้เริ่มกระบวนการยืนยันตัวตนจากเว็บไซต์ของ IdP โดยปกติผู้ใช้จะพบรายชื่อแอปพลิเคชัน SP ที่รองรับบนพอร์ทัลของ IdP ผู้ใช้คลิกที่แอปพลิเคชัน SP และถูกเปลี่ยนเส้นทางไปยังเว็บไซต์ของ SP ด้วยข้อมูลตัวตนที่ยืนยันไว้ล่วงหน้า

SSO เริ่มต้นจาก IdP มักถูกใช้งานโดยองค์กรขนาดใหญ่และหน่วยงานที่พึ่งพาแอปหรือบริการของบุคคลที่สามต่างๆ เช่น Workday, Salesforce เป็นต้น มันให้วิธีการที่เป็นศูนย์กลางในการจัดการการเข้าถึงของผู้ใช้ในแอปพลิเคชันหลายตัวและบังคับใช้การยืนยันตัวตน SSO โดยการเปิดใช้งาน SSO เริ่มต้นจาก IdP พนักงานสามารถเข้าถึงแอปพลิเคชันที่เชื่อมต่อโดยตรงจากพอร์ทัลของ IdP โดยไม่จำเป็นต้องเยี่ยมชมเว็บไซต์ของแต่ละแอปพลิเคชัน ลดระยะเวลาในการเริ่มต้นใช้งานและปรับปรุงประสบการณ์ผู้ใช้
SSO เริ่มต้นจาก IdP มีความเสี่ยงมากกว่าการใช้งาน SSO เริ่มต้นจาก SP
การขาดข้อมูลยืนยันตัวตน: ทุกๆ คำขอยืนยันตัวตนที่เริ่มต้นจาก IdP นั้นไม่มีการขอร้องล่วงหน้า ดังนั้น, SP สามารถเริ่มกระบวนการยืนยันตัวตนได้, ซึ่งอาจเปิดช่องโหว่ในการเข้าถึงที่ไม่ได้รับอนุญาต มีความเสี่ยงที่เซสชันของผู้ใช้งานอาจถูกขโมยได้ นักร้ายอาจเริ่มกระบวนการเข้าสู่ระบบสำหรับผู้ใช้ที่ถูกต้องโดยที่พวกเขาไม่รู้หรือไม่ยินยอม
การคงที่ของเซสชัน: เนื่องจาก SP ไม่ได้เริ่มกระบวนการยืนยันตัวตน, เซสชันของผู้ใช้อาจถูกคงที่ไปที่เซสชันของ IdP ซึ่งอาจนำไปสู่การโจมตีการคงที่ของเซสชันที่ทำให้ผู้โจมตีสามารถคงเซสชันของผู้ใช้ไปที่เซสชันของ IdP และเข้าถึงบัญชีของผู้ใช้งานได้โดยไม่ได้รับอนุญาต
การโจมตีแบบฟิชชิง: SSO เริ่มต้นจาก IdP อาจมีแนวโน้มที่จะถูกโจมตีแบบฟิชชิง นักร้ายอาจหลอกให้ผู้ใช้เยี่ยมชมพอร์ทัลของ IdP ปลอมและขโมยข้อมูลประจำตัวของผู้ใช้ เมื่อผู้ใช้เข้าสู่ระบบ, นักร้ายอาจเปลี่ยนเส้นทางผู้ใช้ไปที่ SP ด้วยข้อมูลตัวตนที่ยืนยันแล้วล่วงหน้า
ไม่มีการยืนยันการร้องขอ: ใน SSO เริ่มต้นจาก SP, ตามปกติแล้ว SP จะรวมข้อมูลความปลอดภัยที่จำเป็นในคำขอไปที่ IdP เพื่อรักษาความสมบูรณ์ของคำขอ เมื่อ SP ได้รับการตอบรับการยืนยันตัวตน, มันจะยืนยันข้อมูลเหล่านี้เพื่อป้องกันการโจมตี CSRF เช่น พารามิเตอร์ state ใน OIDC และ RelayState ใน SAML ทั้งนี้, ใน SSO เริ่มต้นจาก IdP, SP ไม่ได้เริ่มกระบวนการยืนยันตัวตน, ดังนั้น SP ไม่มีการยืนยันการร้องขอ
SSO เริ่มต้นจาก IdP ไม่ได้รับการสนับสนุนโดย OIDC เนื่องจากข้อบกพร่องดังกล่าว OIDC ต้องการให้ SP เริ่มกระบวนการยืนยันตัวตนเพื่อให้มั่นใจในความสมบูรณ์ของคำขอ แม้แต่ในกรณีที่ผู้ใช้เริ่มกระบวนการยืนยันตัวตนจากบุคคลที่สามที่ไม่ใช่ SP, ผู้ใช้ควรถูกพาไปที่ SP ก่อนเพื่อเริ่มกระบวนการยืนยันตัวตน
แต่ใน SAML, SSO เริ่มต้นจาก IdP เป็นไปได้ IdP สามารถสร้างการยืนยัน SAML โดยที่ SP ไม่เริ่มกระบวนการยืนยันตัวตน ใน SSO เริ่มต้นจาก IdP แบบ SAML การยืนยัน SAML ที่ไม่มี RequestID และ RelayState ที่ถูกต้องอาจถูกส่งไปยัง URL ACS ของ SP โดยตรง ซึ่ง SP ควรสามารถจัดการการยืนยันประเภทนี้และให้สิทธิ์เข้าถึงให้ผู้ใช้ได้ (หมายเหตุ: ไม่มี RequestID และ RelayState, SP ไม่มีการยืนยันความสมบูรณ์ของคำขอ)
แม้ว่า SSO เริ่มต้นจาก IdP จะให้วิธีการจัดการการเข้าถึงของผู้ใช้ในแอปพลิเคชันหลายตัว, มันมีความเสี่ยงมากกว่าการใช้งาน SSO เริ่มต้นจาก SP SSO เริ่มต้นจาก SP มีความปลอดภัยมากกว่าและให้ความมั่นใจมากกว่าในความสมบูรณ์ของคำขอยืนยันตัวตน ขอแนะนำให้ใช้ SSO เริ่มต้นจาก SP สำหรับทั้ง OIDC และ SAML