IdP-initiated SSO (SAML เท่านั้น)

IdP-initiated SSO คือกระบวนการ Single Sign-On ที่ผู้ให้บริการข้อมูลระบุตัวตน (Identity provider; IdP) เป็นผู้ควบคุมกระบวนการการยืนยันตัวตนหลัก กระบวนการนี้เริ่มต้นเมื่อผู้ใช้ลงชื่อเข้าใช้แพลตฟอร์มของ IdP เช่น พอร์ทัลของบริษัท หรือแดชบอร์ดศูนย์กลางข้อมูลระบุตัวตน เมื่อยืนยันตัวตนสำเร็จ IdP จะสร้าง SAML assertion และนำผู้ใช้ไปยังผู้ให้บริการบริการ (Service Provider; SP) เพื่อเข้าถึงแอปพลิเคชันหรือบริการ

ความเสี่ยงและข้อควรพิจารณา

IdP-initiated SSO อาจก่อให้เกิดช่องโหว่ด้านความปลอดภัยหลายประการที่องค์กรควรตระหนัก เนื่องจากกระบวนการยืนยันตัวตนถูกเริ่มต้นโดย IdP โดยไม่มีคำขอโดยตรงจากผู้ใช้ จึงอาจตกเป็นเป้าของการโจมตีหลายรูปแบบ เช่น Cross-Site Request Forgery (CSRF)

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

ดังนั้นจึงแนะนำอย่างยิ่งให้ใช้ SP-initiated SSO ซึ่งให้กระบวนการยืนยันตัวตนที่ปลอดภัยและควบคุมได้มากกว่า โดยให้ผู้ใช้ร้องขอเข้าถึงบริการอย่างชัดเจน

เชื่อมต่อ IdP-initiated SSO กับแอปพลิเคชัน Logto OIDC

Logto ในฐานะผู้ให้บริการ OpenID Connect (OIDC) ไม่รองรับ IdP-initiated SSO โดยตรง อย่างไรก็ตาม คุณสามารถตั้งค่า Logto เป็น SP เพื่อรองรับ IdP-initiated SSO กับ IdP ขององค์กรคุณผ่าน SAML การตั้งค่านี้ช่วยให้คุณใช้ความสามารถด้านการยืนยันตัวตนของ Logto ขณะยังคงให้ IdP ควบคุมกระบวนการยืนยันตัวตน

บันทึก:

โดยค่าเริ่มต้น ฟีเจอร์นี้จะไม่เปิดใช้งานใน Logto หากคุณต้องการเปิดใช้ IdP-initiated SSO สำหรับ tenant ของคุณ กรุณาติดต่อ ทีมสนับสนุนของเรา

ข้อกำหนดเบื้องต้น

ก่อนตั้งค่า IdP-initiated SSO คุณต้องสร้างตัวเชื่อมต่อ SAML ก่อน โดยไปที่ Console > Enterprise SSO และทำตามคู่มือทีละขั้นตอนเพื่อสร้าง SAML connector กับ IdP ของคุณ

เมื่อสร้าง SAML connector แล้ว คุณสามารถเปิดใช้งานวิธีลงชื่อเข้าใช้ SSO ได้ใน Sign-in & account > Sign-up and sign-in และทดสอบ SP-initiated SSO flow เพื่อให้แน่ใจว่าการตั้งค่าถูกต้อง ตรวจสอบให้แน่ใจว่า SP-initiated SSO ทำงานได้ตามที่คาดหวังก่อนดำเนินการกับ IdP-initiated SSO

เปิดใช้งาน IdP-initiated SSO

เมื่อเปิดใช้งานฟีเจอร์ IdP-initiated SSO สำหรับ tenant ของคุณแล้ว คุณจะเห็นแท็บเพิ่มเติมในหน้าตั้งค่าของ SAML connector ชื่อว่า IdP-initiated SSO เปิดสวิตช์ IdP-initiated SSO เพื่อเปิดใช้งานฟีเจอร์นี้สำหรับตัวเชื่อมต่อ

เลือกแอปพลิเคชัน SP

ต่างจาก SP-initiated SSO ที่ flow เริ่มจาก SP, IdP-initiated SSO ต้องการแอปพลิเคชัน SP ฝั่ง client เพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากกระบวนการยืนยันตัวตน คุณสามารถเลือกแอปพลิเคชัน SP จากรายชื่อแอปพลิเคชันที่ลงทะเบียนไว้ใน dropdown Default application

รองรับเฉพาะแอปพลิเคชัน Traditional Web App และ Single Page App สำหรับ IdP-initiated SSO เท่านั้น โปรดเลือกประเภทแอปพลิเคชันให้เหมาะสมกับกรณีการใช้งานของคุณ

บันทึก:

ในฝั่ง IdP ของคุณ ให้เว้นค่า RelayState เป็น EMPTY เพื่อให้ IdP-initiated SSO flow ทำงานได้ถูกต้อง Logto จะจัดการการเปลี่ยนเส้นทางตาม SP application ที่เลือกไว้โดยอัตโนมัติ

ตั้งค่ากระบวนการยืนยันตัวตนแบบ IdP-initiated

เพื่อเชื่อมต่อ IdP-initiated SAML SSO กับ OIDC, Logto มีตัวเลือกการตั้งค่าสองแบบเพื่อจัดการคำขอการยืนยันตัวตน

ตัวเลือก A: เปลี่ยนเส้นทางไปยัง SP application เริ่มต้น (แนะนำ)

เมื่อ IdP เริ่มต้น SSO flow และส่ง SAML assertion ไปยัง Logto จะมีการสร้าง session ของ IdP-initiated SSO assertion ขึ้น Logto จะเปลี่ยนเส้นทางผู้ใช้ไปยัง SP application เริ่มต้นเพื่อเริ่มต้นคำขอการยืนยันตัวตน OIDC มาตรฐานที่ฝั่ง client

เพื่อใช้ตัวเลือกนี้ ให้เลือกการ์ด Redirect to client for SP-initiated authentication ในแท็บ IdP-initiated SSO ของหน้าตั้งค่า SAML connector

1. กำหนด Client redirect URL เพื่อเปลี่ยนเส้นทางผู้ใช้ไปยัง SP application เริ่มต้นหลังจาก IdP-initiated SSO flow เสร็จสิ้น Logto จะเปลี่ยนเส้นทางผู้ใช้ไปยัง URL นี้พร้อม query parameter ?ssoConnectorId={connectorId} ต่อท้าย URL แอป client ควรจัดการการเปลี่ยนเส้นทางนี้และเริ่มต้นคำขอการยืนยันตัวตน OIDC (แนะนำให้ใช้ route หรือหน้าพิเศษในแอป client เพื่อจัดการคำขอ IdP-initiated SSO authentication)

2. จัดการคำขอการยืนยันตัวตน OIDC ที่ฝั่ง client โดยใช้ query parameter ssoConnectorId เพื่อระบุ SAML connector ที่เริ่มต้น IdP-initiated SSO authentication flow

3. ส่งพารามิเตอร์ direct sign-in ในคำขอลงชื่อเข้าใช้ไปยัง Logto เพื่อให้ flow SSO authentication สมบูรณ์

// React example
import { Prompt, useLogto } from '@logto/react';
import { useEffect } from 'react';
import { useNavigate, useSearchParams } from 'react-router-dom';

const SsoDirectSignIn = () => {
  const { signIn } = useLogto();
  const [searchParams] = useSearchParams();

  useEffect(() => {
    const ssoConnectorId = searchParams.get('ssoConnectorId');
    if (ssoConnectorId) {
      void signIn({
        redirectUri,
        prompt: Prompt.Login,
        directSignIn: {
          method: 'sso',
          target: ssoConnectorId,
        },
      });
    }
  }, [searchParams, signIn]);
};

• redirectUri: redirect_uri ที่จะเปลี่ยนเส้นทางผู้ใช้หลังจาก flow การยืนยันตัวตน OIDC เสร็จสมบูรณ์
• prompt=login: บังคับให้ผู้ใช้ลงชื่อเข้าใช้ด้วยตัวตน IdP-initiated SSO
• directSignIn=sso:{connectorId}: ระบุวิธี direct sign-in เป็น sso และ target SAML connector ID พารามิเตอร์นี้จะทำให้ flow SSO authentication ทำงานโดยตรงโดยไม่แสดงหน้า login ผู้ใช้จะได้รับการยืนยันตัวตนาอัตโนมัติด้วย session ของ IdP-initiated SSO assertion ที่เก็บไว้ หาก connector ID ตรงกันและ session ยัง valid

วิธีนี้ช่วยให้ flow การยืนยันตัวตนปลอดภัยและเป็นไปตามมาตรฐาน OIDC protocol ขณะยังคงให้ IdP ควบคุมกระบวนการยืนยันตัวตน แอป client สามารถใช้ session ของ IdP-initiated SSO assertion เพื่อยืนยันตัวตนผู้ใช้โดยไม่ต้องมีขั้นตอน login เพิ่มเติม ขณะเดียวกันก็ยังคงความปลอดภัยและการควบคุม flow การยืนยันตัวตนไว้ได้ แอป client ยังสามารถตรวจสอบพารามิเตอร์ state และ PKCE เพื่อความปลอดภัยของคำขอการยืนยันตัวตน

บันทึก:

วิธีนี้ใช้ได้กับทั้งแอป Traditional Web App และ Single Page App และแนะนำสำหรับทุกกรณีการใช้งาน

ตัวเลือก B: ยืนยันตัวตนผู้ใช้โดยตรงด้วย IdP-initiated SSO

ในบางกรณี SP อาจไม่สามารถจัดการ callback ของ IdP-initiated SSO และเริ่มต้นคำขอการยืนยันตัวตน OIDC ได้ ในกรณีนี้ Logto มีตัวเลือกสำรองให้ยืนยันตัวตนผู้ใช้โดยตรงด้วย session ของ IdP-initiated SSO assertion

ตัวเลือกนี้ถือว่ามีความปลอดภัยน้อยกว่าและไม่แนะนำ เพราะ flow การยืนยันตัวตนจะข้ามมาตรฐาน OIDC protocol ไป เนื่องจากคำขอการยืนยันตัวตนถูกเริ่มโดย IdP แอป client อาจไม่สามารถตรวจสอบคำขอการยืนยันตัวตนได้อย่างปลอดภัย เช่น ไม่สามารถตรวจสอบพารามิเตอร์ state และ PKCE เพื่อความปลอดภัยของคำขอได้

คำเตือน:

วิธีนี้ไม่รองรับแอป Single Page App เนื่องจากต้องให้แอป client จัดการคำขอการยืนยันตัวตนอย่างปลอดภัยด้วยพารามิเตอร์ PKCE หากคุณต้องการใช้ IdP-initiated SSO กับ SPA กรุณาใช้ตัวเลือกด้านบนแทน

เพื่อใช้ตัวเลือกนี้ ให้เลือก Directly sign-in using IdP-initiated SSO ในแท็บ IdP-initiated SSO ของหน้าตั้งค่า SAML connector

1. เลือก Post sign-in redirect URI เพื่อเปลี่ยนเส้นทางผู้ใช้กลับไปยังแอป client หลังจากยืนยันตัวตนสำเร็จ URL นี้จะถูกใช้เป็น redirect_uri ในคำขอการยืนยันตัวตน OIDC โดย URI ต้องเป็นหนึ่งใน redirect URI ที่ลงทะเบียนไว้ในแอป client

   บันทึก:

   แนะนำอย่างยิ่งให้ใช้ redirect URI เฉพาะสำหรับ IdP-initiated SSO เนื่องจากคำขอการยืนยันตัวตนนี้ไม่ได้ร้องขอโดยตรง แอป client ควรจัดการ response นี้แยกจาก flow การยืนยันตัวตนแบบ SP-initiated มาตรฐาน

2. ปรับแต่งพารามิเตอร์คำขอ authorization ได้หากต้องการ โดยใช้ json editor Additional authentication parameters (ตาม type Map<string,string>)

   ตัวอย่าง โดยปกติ Logto จะขอเพียง openid และ profile scopes คุณสามารถเพิ่ม scopes หรือพารามิเตอร์เพิ่มเติมในคำขอการยืนยันตัวตนได้

   {
     "scope": "email offline_access"
   }

   • เพิ่ม scope email เพื่อขอที่อยู่อีเมลของผู้ใช้
   • เพิ่ม scope offline_access เพื่อขอโทเค็นรีเฟรช

   แนะนำให้คุณกำหนดพารามิเตอร์ state แบบกำหนดเองเพื่อใช้ตรวจสอบ response ของการยืนยันตัวตนอย่างปลอดภัย

   {
     "state": "custom-state-value"
   }

   แอป client ควรตรวจสอบพารามิเตอร์ state ใน response ของ authorization code เพื่อให้แน่ใจว่าคำขอการยืนยันตัวตนถูกต้อง