SSO เริ่มต้นจาก IdP กับ SSO เริ่มต้นจาก SP

คำศัพท์#

• ผู้ให้บริการข้อมูลประจำตัว (IdP): บริการที่เก็บและยืนยันตัวตนของผู้ใช้
• ผู้ให้บริการ (SP): เว็บหรือบริการที่ให้บริการแก่ผู้ใช้
• การเข้าสู่ระบบครั้งเดียว (SSO): บริการเซสชันและการยืนยันตัวตนที่อนุญาตให้ผู้ใช้ใช้ข้อมูลการเข้าสู่ระบบชุดเดียว (เช่น ชื่อและรหัสผ่าน) ในการเข้าถึงแอปพลิเคชันหลายตัว
• SAML: Security Assertion Markup Language เป็นมาตรฐานเปิดสำหรับแลกเปลี่ยนข้อมูลการยืนยันตัวตนและอนุญาตระหว่างบุคคลสองฝ่าย โดยเฉพาะ ระหว่างผู้ให้บริการข้อมูลประจำตัวและผู้ให้บริการ เป็นโปรโตคอลที่ใช้ทั่วไปสำหรับ SSO เมื่อผู้ใช้ยืนยันตัวตนสำเร็จโดย IdP, IdP จะส่งการยืนยัน SAML ไปยัง SP ซึ่ง SP จะยืนยันและอนุญาตการเข้าถึงให้ผู้ใช้
• OIDC: OpenID Connect เป็นโปรโตคอลที่ทันสมัยและปลอดภัยมากขึ้นสำหรับ SSO มันถูกสร้างขึ้นบน OAuth 2.0 และให้วิธีในการยืนยันตัวตนของผู้ใช้โดยอิงจากการยืนยันที่ดำเนินการโดย IdP เมื่อผู้ใช้ยืนยันตัวตนสำเร็จโดย IdP, IdP จะส่งโทเค็นในรูปแบบ JWT ไปยัง SP ซึ่ง SP จะยืนยันและอนุญาตการเข้าถึงให้ผู้ใช้

SSO เริ่มต้นจาก SP#

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

1. ผู้ใช้เข้าชมเว็บไซต์ของ SP และพยายามเข้าถึงทรัพยากร
2. ผู้ใช้คลิกปุ่มเข้าสู่ระบบ SSO (เช่น Google, Azure AD, Okta, ฯลฯ)
3. SP เปลี่ยนเส้นทางผู้ใช้ไปที่ IdP เพื่อการยืนยันตัวตน
4. ผู้ใช้เข้าสู่ระบบที่ IdP
5. IdP ส่งโทเค็นหรือการยืนยันกลับไปที่ SP
6. SP ยืนยันโทเค็นหรือการยืนยันและให้สิทธิ์เข้าถึงแก่ผู้ใช้

SSO เริ่มต้นจาก IdP#

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

1. ผู้ใช้เข้าสู่ระบบที่ IdP
2. ผู้ใช้เข้าชมพอร์ทัลของ IdP และเลือกแอปพลิเคชัน SP
3. IdP ยืนยันเซสชันปัจจุบันของผู้ใช้และเปลี่ยนเส้นทางผู้ใช้ไปยัง SP ด้วยข้อมูลตัวตน SSO ที่ยืนยันไว้ล่วงหน้า
4. SP ยืนยันข้อมูลตัวตน SSO และให้สิทธิ์เข้าถึงแก่ผู้ใช้

การเปรียบเทียบระหว่าง SSO เริ่มต้นจาก IdP กับ SSO เริ่มต้นจาก SP#

ข้อดีของ SSO เริ่มต้นจาก IdP เมื่อเปรียบเทียบกับ SSO เริ่มต้นจาก SP#

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

ความเสี่ยงของ SSO เริ่มต้นจาก IdP เมื่อเปรียบเทียบกับ SSO เริ่มต้นจาก SP#

SSO เริ่มต้นจาก IdP มีความเสี่ยงมากกว่าการใช้งาน SSO เริ่มต้นจาก SP

1. การขาดข้อมูลยืนยันตัวตน: ทุกๆ คำขอยืนยันตัวตนที่เริ่มต้นจาก IdP นั้นไม่มีการขอร้องล่วงหน้า ดังนั้น, SP สามารถเริ่มกระบวนการยืนยันตัวตนได้, ซึ่งอาจเปิดช่องโหว่ในการเข้าถึงที่ไม่ได้รับอนุญาต มีความเสี่ยงที่เซสชันของผู้ใช้งานอาจถูกขโมยได้ นักร้ายอาจเริ่มกระบวนการเข้าสู่ระบบสำหรับผู้ใช้ที่ถูกต้องโดยที่พวกเขาไม่รู้หรือไม่ยินยอม

2. การคงที่ของเซสชัน: เนื่องจาก SP ไม่ได้เริ่มกระบวนการยืนยันตัวตน, เซสชันของผู้ใช้อาจถูกคงที่ไปที่เซสชันของ IdP ซึ่งอาจนำไปสู่การโจมตีการคงที่ของเซสชันที่ทำให้ผู้โจมตีสามารถคงเซสชันของผู้ใช้ไปที่เซสชันของ IdP และเข้าถึงบัญชีของผู้ใช้งานได้โดยไม่ได้รับอนุญาต

3. การโจมตีแบบฟิชชิง: SSO เริ่มต้นจาก IdP อาจมีแนวโน้มที่จะถูกโจมตีแบบฟิชชิง นักร้ายอาจหลอกให้ผู้ใช้เยี่ยมชมพอร์ทัลของ IdP ปลอมและขโมยข้อมูลประจำตัวของผู้ใช้ เมื่อผู้ใช้เข้าสู่ระบบ, นักร้ายอาจเปลี่ยนเส้นทางผู้ใช้ไปที่ SP ด้วยข้อมูลตัวตนที่ยืนยันแล้วล่วงหน้า

4. ไม่มีการยืนยันการร้องขอ: ใน SSO เริ่มต้นจาก SP, ตามปกติแล้ว SP จะรวมข้อมูลความปลอดภัยที่จำเป็นในคำขอไปที่ IdP เพื่อรักษาความสมบูรณ์ของคำขอ เมื่อ SP ได้รับการตอบรับการยืนยันตัวตน, มันจะยืนยันข้อมูลเหล่านี้เพื่อป้องกันการโจมตี CSRF เช่น พารามิเตอร์ state ใน OIDC และ RelayState ใน SAML ทั้งนี้, ใน SSO เริ่มต้นจาก IdP, SP ไม่ได้เริ่มกระบวนการยืนยันตัวตน, ดังนั้น SP ไม่มีการยืนยันการร้องขอ

ข้อจำกัดของ SSO เริ่มต้นจาก IdP เมื่อเปรียบเทียบกับ SSO เริ่มต้นจาก 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