จัดระเบียบการเข้าสู่ระบบแบบข้ามโดเมน

Eiji Kitamura

สถาปัตยกรรมทางธุรกิจสมัยใหม่มักครอบคลุมโดเมนที่แตกต่างกันหลายโดเมน องค์กรจะดูแลสภาพแวดล้อมเฉพาะสำหรับฟีเจอร์ต่างๆ เช่น brand.example สำหรับการตลาด service-app.example สำหรับผลิตภัณฑ์หลัก และ support-portal.example สำหรับการบริการลูกค้า ในอุดมคติ คุณต้องการมอบประสบการณ์การลงชื่อเพียงครั้งเดียวที่ รวมเป็นหนึ่งเดียวเมื่อผู้ใช้ไปยังพร็อพเพอร์ตี้เหล่านี้ อย่างไรก็ตาม ทีมวิศวกรมักจะผสานรวมโดเมนเหล่านี้โดยใช้เทคนิคเฉพาะกิจ ซึ่งทำให้เกิดการแยกส่วน ซึ่งจะขัดขวางการจัดการข้อมูลเข้าสู่ระบบของเบราว์เซอร์ในตัว โดยการหยุดโฟลว์การป้อนข้อความอัตโนมัติของเครื่องมือจัดการรหัสผ่านและชะลอการนำพาสคีย์มาใช้

การแยกส่วนข้อมูลระบุตัวตนแบบข้ามโดเมนในพร็อพเพอร์ตี้เว็บหลายรายการ

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

ดูวิธีใช้มาตรฐานและโซลูชันด้านสถาปัตยกรรม (เช่น ข้อมูลเมตา iframe ข้ามต้นทาง การรวมข้อมูลประจำตัว และการรวมโดเมนย่อย) เพื่อ แก้ไขการกระจายตัวของข้อมูลประจำตัวข้ามโดเมน และมอบเส้นทางของผู้ใช้ที่ราบรื่น

วิธีแก้ปัญหาเบื้องต้นที่พบบ่อย

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

คำขอเรียกข้อมูล CORS

เมื่อโดเมนทำงานอย่างอิสระ ฟรอนท์เอนด์มักจะอาศัยคำขอข้ามต้นทาง fetch()ที่ส่งไปยัง API การตรวจสอบสิทธิ์แบบรวมศูนย์ ซึ่งสามารถอนุญาตได้อย่างปลอดภัยโดยใช้การแชร์ทรัพยากรข้ามโดเมน (CORS) เนื่องจากเบราว์เซอร์มักจะบล็อกหรือจำกัดคุกกี้ข้ามเว็บไซต์ นักพัฒนาแอปจึงอาจออกแบบ API เหล่านี้อย่างชัดเจนเพื่อส่งคืนโทเค็นการตรวจสอบสิทธิ์ เช่น โทเค็นเว็บ JSON (JWT) ภายในเพย์โหลด JSON แทนที่จะใช้ส่วนหัว Set-Cookie

การแชร์ฐานข้อมูลบัญชี

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

ปัญหาเกี่ยวกับการลงชื่อเข้าใช้ที่ไม่ต่อเนื่อง

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

การกระจายตัวของเครื่องมือจัดการรหัสผ่าน

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

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

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

เกตเวย์ฟิชชิง

การหยุดชะงักนี้ทำหน้าที่เป็นเกตเวย์ฟิชชิง การปฏิเสธของเครื่องมือจัดการรหัสผ่าน ที่จะป้อนข้อความอัตโนมัติในโดเมนที่ไม่รู้จักเป็นกลไกการป้องกันหลัก การกำหนดให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบด้วยตนเองใน URL ต่างๆ โดยไม่ตั้งใจจะฝึกให้ผู้ใช้ตกเป็นเหยื่อของการโจมตีแบบฟิชชิง

Roadblock ของพาสคีย์

ความยุ่งยากจะเพิ่มขึ้นเมื่อคุณใช้พาสคีย์ สถาปัตยกรรมการรักษาความปลอดภัยหลักของ WebAuthn จะเชื่อมโยงพาสคีย์กับการเข้ารหัสอย่างเคร่งครัดกับรหัสผู้ให้บริการ (RP ID) ที่ระบุ

ซึ่งจะสร้าง "กับดักรหัส RP" พาสคีย์ที่ลงทะเบียนใน brand.example จะใช้ใน service-app.example ไม่ได้เนื่องจากเบราว์เซอร์ปฏิเสธการเข้าถึงข้ามโดเมน หากต้องการหลีกเลี่ยงการแจ้งให้ผู้ใช้ลงทะเบียนพาสคีย์ที่แตกต่างกันสำหรับทุกเว็บไซต์ คุณต้องรวมพร็อพเพอร์ตี้เหล่านี้ไว้ในรหัส RP เดียว

แนวทางที่แนะนำ

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

• ใช้ไฟล์การกำหนดค่าข้อมูลเมตา: โฮสต์ไฟล์ข้อมูลเมตา เช่น Digital Asset Links และคำขอต้นทางที่เกี่ยวข้อง เพื่อสร้างห่วงโซ่ความน่าเชื่อถือด้านการเข้ารหัส ซึ่งช่วยให้แชร์ข้อมูลเข้าสู่ระบบ และพาสคีย์ได้อย่างราบรื่นในโดเมนและแอปบนอุปกรณ์เคลื่อนที่ต่างๆ แนวทางนี้ เป็นการแก้ไขการกระจายตัวของข้อมูลประจำตัวแบบเงียบๆ ที่มีต้นทุนต่ำ ซึ่งไม่จำเป็นต้อง ปรับโครงสร้างพื้นฐานเว็บที่มีอยู่ใหม่ให้ซับซ้อน
• ใช้ iframe แบบข้ามต้นทาง: ฝังต้นทางการตรวจสอบสิทธิ์ส่วนกลางเป็น iframe ภายในผู้ให้บริการที่เชื่อถือเพื่อเชื่อมโยงข้อมูลเข้าสู่ระบบและพาสคีย์ที่บันทึกไว้ในเว็บไซต์ต่างๆ แนวทางนี้ ใช้นโยบายสิทธิ์และคุกกี้ที่แบ่งพาร์ติชันเพื่อมอบประสบการณ์การลงชื่อเข้าใช้ที่ราบรื่น ในบริบท ขณะเดียวกันก็รักษาขอบเขตด้านความปลอดภัยที่เข้มงวด ผ่าน CSP และการรับส่งข้อความข้ามเอกสาร
• ทำตามการรวมข้อมูลประจำตัวมาตรฐาน ใช้โปรโตคอลมาตรฐานอุตสาหกรรม เช่น OpenID Connect เพื่อรวมศูนย์ การตรวจสอบสิทธิ์ในโดเมนผู้ให้บริการข้อมูลประจำตัว (IdP) โดยเฉพาะ ซึ่งจะ กำหนดเส้นทางการเข้าสู่ระบบอย่างเป็นทางการผ่านการเปลี่ยนเส้นทางที่ปลอดภัย เพื่อแทนที่การผสานรวมที่เปราะบาง ด้วยโซลูชันของบุคคลที่หนึ่งที่เชื่อถือได้และปรับขนาดได้
• รวมโดเมนย่อย: เปลี่ยนไปใช้ โดเมนย่อยภายใต้รูททั่วไป ซึ่งจะช่วยให้แชร์เซสชันได้อย่างราบรื่น ผ่านคุกกี้ไวลด์การ์ดและความต่อเนื่องของพาสคีย์ในโดเมนที่ลงทะเบียนได้ทั้งหมด โปรแกรมจัดการรหัสผ่านหลายโปรแกรมสามารถจดจำรูทโดเมนที่แชร์ และแนะนำข้อมูลเข้าสู่ระบบที่บันทึกไว้โดยอัตโนมัติในโดเมนย่อยที่เกี่ยวข้อง

ใช้ไฟล์การกำหนดค่าข้อมูลเมตา

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

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

ใช้ไฟล์การกำหนดค่า 2 ไฟล์ที่แตกต่างกันเพื่อให้ครอบคลุมแพลตฟอร์มและระบบนิเวศที่แตกต่างกัน

• เครื่องมือจัดการรหัสผ่านบน Android และ Chrome ของ Google: โฮสต์ไฟล์ JSON ของ ลิงก์เนื้อหาดิจิทัล (DAL) ที่ /.well-known/assetlinks.json เพื่อสร้างความสัมพันธ์ที่เชื่อถือได้ซึ่งยืนยันได้ ระหว่างแอปและเว็บไซต์ที่เชื่อมโยงขององค์กร ความน่าเชื่อถือนี้ช่วยให้ Deep Link ในแอปและการแชร์ข้อมูลเข้าสู่ระบบที่ราบรื่นทำงานได้ โดยรหัสผ่านที่บันทึกไว้บนเว็บจะป้อนข้อมูลอัตโนมัติในเว็บไซต์ที่เชื่อมโยง (แม้ว่าการแชร์พาสคีย์ในโดเมนเว็บหลายโดเมนยังคงต้องใช้ คำขอต้นทางที่เกี่ยวข้อง) ดูข้อมูลเพิ่มเติมได้ในคำแนะนำเกี่ยวกับการแชร์ข้อมูลเข้าสู่ระบบอย่างราบรื่น

• รหัสผ่าน Apple ใน iOS และ Safari: โฮสต์ไฟล์ Apple App Site Association (AASA) ที่ /.well-known/apple-app-site-association เพื่อสร้าง ห่วงโซ่ความน่าเชื่อถือทางคริปโตกราฟีที่จำเป็นสำหรับการเชื่อมโยงสถานะรหัสผ่าน Apple ในแอป iOS และ Safari คุณสามารถประกาศโดเมนที่เชื่อมโยงเหล่านี้จากส่วนกลางได้โดยใช้ที่เก็บที่รวบรวมข้อมูลจากมวลชนเพื่อรองรับระบบนิเวศของบุคคลที่สาม การดำเนินการนี้จะช่วยให้เครื่องมืออิสระ (เช่น 1Password ซึ่งใช้ที่เก็บข้อมูลนี้อย่างชัดเจน) รู้จักบริบทข้อมูลประจำตัวที่แชร์ด้วย หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับ App Site Association ของ Apple โปรดอ่านการรองรับโดเมนที่เชื่อมโยง

หากต้องการเปิดใช้พาสคีย์ในโดเมนเว็บต่างๆ และแก้ไขปัญหา คำขอต้นทางที่เกี่ยวข้อง (ROR) ที่ทำให้ไม่สามารถใช้พาสคีย์ได้ นักพัฒนาแอปสามารถโฮสต์ไฟล์ที่ /.well-known/webauthn ROR ประกาศอย่างชัดเจนว่าโดเมนที่ได้รับอนุญาต ซึ่งได้รับอนุญาตให้แชร์รหัส RP ของพาสคีย์เดียวกันอย่างปลอดภัย ดูข้อมูลเพิ่มเติม เกี่ยวกับคำขอต้นทางที่เกี่ยวข้องได้ที่ อนุญาตให้ใช้รหัสผ่านแบบพาสคีย์ซ้ำในเว็บไซต์ของคุณด้วยคำขอต้นทางที่เกี่ยวข้อง

• ข้อดี:
  • การแก้ไขเบื้องหลังสำหรับผู้ใช้ปลายทาง: การแก้ไขนี้ทำงานในเบื้องหลังทั้งหมด ซึ่งจะแก้ปัญหาการกระจายตัวของการป้อนข้อความอัตโนมัติโดยอัตโนมัติและสร้าง ความต่อเนื่องของพาสคีย์ที่ระดับระบบปฏิบัติการหรือเบราว์เซอร์โดยไม่มีการเปลี่ยนแปลงที่มองเห็นได้ ใน UX
  • การติดตั้งใช้งานที่ง่าย: โซลูชันนี้มีต้นทุนต่ำ โดยต้องมีการโฮสต์ไฟล์ JSON แบบคงที่เท่านั้น ไม่จำเป็นต้องมีการปรับโครงสร้างแบ็กเอนด์ ใหม่หรือตรรกะการแลกเปลี่ยนโทเค็นที่ซับซ้อน
  • รักษาโครงสร้างพื้นฐานที่มีอยู่: คุณสามารถปรับปรุงเส้นทางข้ามโดเมนได้อย่างมากโดยไม่ต้องเปลี่ยนแบรนด์หรือรวมโดเมน
• ข้อเสีย:
  • ข้อจำกัดของแพลตฟอร์ม: โดยปกติแล้ว แพลตฟอร์มจะบังคับใช้ขีดจำกัดที่เข้มงวดกับ ROR เช่น Chrome จำกัดรหัส RP เดียวให้มีป้ายกำกับ eTLD+1 ที่เชื่อมโยงได้สูงสุด 5 รายการ ตัวอย่างเช่น example.co.uk และ example.de มีป้ายกำกับ example eTLD+1 เดียวกัน แต่ example-rewards.com ใช้ป้ายกำกับ example-rewards แยกต่างหาก หากคุณ จัดการพอร์ตโฟลิโอโดเมนที่กว้างขวางหรือหลากหลาย ขีดจำกัดเหล่านี้อาจ ไม่เพียงพอ
  • เวลาในการตอบสนองในการดำเนินการเพิ่มขึ้น: การแก้ไขไฟล์ข้อมูลเมตาต้องมีการ ไปกลับของเครือข่ายเพิ่มเติม ซึ่งจะเพิ่มเวลาในการตอบสนองเมื่อเบราว์เซอร์ประมวลผล การตรวจสอบสิทธิ์

การใช้ไฟล์กำหนดค่าข้อมูลเมตาเพื่อเปิดใช้การแชร์ข้อมูลเข้าสู่ระบบ

ใช้ iframe แบบข้ามต้นทาง

หากคุณไม่สามารถใช้วิธีไฟล์กำหนดค่าข้อมูลเมตาเนื่องจากข้อจำกัดของโดเมน ROR องค์ประกอบ iframe แบบข้ามต้นทางจะช่วยให้คุณมีเส้นทางที่เชื่อถือได้และรองรับมาตรฐานในการแก้ปัญหาการลงชื่อเข้าใช้แบบข้ามโดเมน

การฝังต้นทางการตรวจสอบสิทธิ์แบบรวมศูนย์ (เช่น auth.brand.example) เป็น iframe ภายในผู้ให้บริการที่เชื่อถือได้ (เช่น brand.example) จะช่วยให้คุณโต้ตอบได้ทั้งกับช่องแบบฟอร์มปกติและ API ที่ทันสมัย สำหรับรหัสผ่าน ตัวจัดการข้อมูลเข้าสู่ระบบของเบราว์เซอร์จะเชื่อมโยงการดำเนินการป้อนข้อความอัตโนมัติ กับต้นทางของ iframe (auth.example) ซึ่งช่วยให้ผู้ใช้เข้าถึง ข้อมูลเข้าสู่ระบบแบบรวมศูนย์ได้อย่างราบรื่นในเว็บไซต์ต่างๆ

สำหรับพาสคีย์ หน้าต่างหลักต้องให้สิทธิ์เข้าถึง iframe โดยใช้เฟรมเวิร์ก นโยบายสิทธิ์ ซึ่งจะช่วยให้ iframe เรียกใช้ WebAuthn เพื่อตรวจสอบสิทธิ์กับรหัส RP ของต้นทางของตัวเองได้ ในทั้ง 2 โฟลว์ CSP (นโยบายรักษาความปลอดภัยเนื้อหา) มีประโยชน์ในการปกป้อง ผู้ใช้จากการโจมตี เช่น การคลิกแจ็กกิ้งและ Cross-site Scripting เมื่อการตรวจสอบสิทธิ์สำเร็จ ระบบจะสร้างเซสชันด้วยคุกกี้ที่แบ่งพาร์ติชัน และส่งโทเค็นกลับไปยังหน้าต่างหลักอย่างปลอดภัยโดยใช้ postMessage()

• ข้อดี:
  • ข้อมูลเข้าสู่ระบบแบบรวมศูนย์: หลีกเลี่ยงการกระจายข้อมูลเข้าสู่ระบบ ต้นทางแบบรวมศูนย์เดียวจะจัดการทั้งรหัสผ่านที่บันทึกไว้และ RP ID ของพาสคีย์แบบรวม ซึ่งช่วยให้โดเมนที่แตกต่างกันแชร์ข้อมูลเข้าสู่ระบบเหล่านี้ได้โดยไม่ต้องรวมโดเมน
  • การตรวจสอบสิทธิ์ตามบริบท: ขั้นตอนการลงชื่อเข้าใช้ทั้งหมด ไม่ว่าจะเป็นการ ป้อนรหัสผ่านอัตโนมัติหรือการยืนยันด้วยพาสคีย์ จะเกิดขึ้นอย่างราบรื่น ในบริบทภายในหน้าหลัก โดยหลีกเลี่ยงการเปลี่ยนเส้นทางแบบรวมศูนย์ที่รบกวน
  • ความยืดหยุ่นในการป้องกันการติดตาม: วิธีนี้จะทํางานได้อย่างถูกต้องแม้ภายใต้การป้องกันการติดตามข้ามเว็บไซต์ที่เข้มงวดโดยใช้คุกกี้ที่แบ่งพาร์ติชัน
• ข้อเสีย:
  • ข้อจำกัดในการติดตั้งใช้งาน: สถาปัตยกรรมนี้ต้องใช้ วิศวกรรมเฉพาะทาง โดยต้องใช้ CSP ที่เข้มงวด (frame-ancestors) เพื่อจำกัดการฝัง ไปยังโดเมนหลักที่เชื่อถือได้และป้องกันการคลิกแจ็กกิ้ง การกำหนดค่านโยบายสิทธิ์ HTTP เพื่อเปิดใช้ WebAuthn API และการรับส่งข้อความข้ามเอกสารที่ปลอดภัยและผ่านการตรวจสอบ (postMessage()) เพื่อ ลดการโจมตีแบบปลอมต้นทางและ CSRF ดูแนวทางปฏิบัติแนะนำได้ที่ พาสคีย์ภายใน iframe

ขั้นตอนการตรวจสอบสิทธิ์ iframe แบบข้ามต้นทาง

ทำตามการรวมศูนย์ข้อมูลระบบตัวตนมาตรฐาน

การใช้การรวมศูนย์ข้อมูลประจำตัวมาตรฐาน เช่น OpenID Connect เป็นแนวทางที่แข็งแกร่งและ ยั่งยืนในการดูแลรักษาระบบบัญชี แนวทางนี้จะกำหนดเวิร์กโฟลว์การตรวจสอบสิทธิ์อย่างเป็นทางการโดยการรวมไว้ในโดเมนผู้ให้บริการข้อมูลประจำตัว (IdP) โดเมนเดียวโดยเฉพาะ เช่น auth.brand.example เมื่อมีโปรโตคอลที่กำหนดไว้ แอปพลิเคชันจะเปลี่ยนเส้นทางผู้ใช้ไปยังฮับส่วนกลางนี้ เพื่อทำการตรวจสอบสิทธิ์ก่อนที่จะรับการโอนโทเค็นอย่างปลอดภัยเพื่อดำเนินการ เข้าสู่ระบบในโดเมนเป้าหมายให้เสร็จสมบูรณ์ แม้ว่ามักจะเชื่อมโยงกับการเข้าสู่ระบบของบุคคลที่สาม (เช่น ลงชื่อเข้าใช้ด้วย Google) แต่การรวมระบบมาตรฐานก็ยังคงใช้ได้และมีการใช้อย่างแพร่หลายในฐานะโซลูชันของบุคคลที่หนึ่ง เพื่อแทนที่วิธีแก้ปัญหาที่ซับซ้อน

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

ขั้นตอนการรวมข้อมูลประจำตัวมาตรฐาน

รวมโดเมนย่อย

อีกแนวทางหนึ่งในการจัดโครงสร้างคือการรวมโดเมนทั้งหมดเข้าด้วยกันโดยย้ายพร็อพเพอร์ตี้ดิจิทัลที่แตกต่างกันไปไว้ภายใต้โดเมนรากที่จดทะเบียนร่วมกัน (eTLD+1) ซึ่งเกี่ยวข้องกับการเปลี่ยนโดเมนแยกต่างหาก เช่น brand.example และ service-app.example ให้เป็นโดเมนย่อย เช่น www.brand.example และ service.brand.example

• ข้อดี:
  • การจัดการข้อมูลเข้าสู่ระบบแบบรวม: เครื่องมือจัดการรหัสผ่านจะจดจำโดเมนรูทและถือว่าโดเมนย่อยทั้งหมดเป็นรายการเดียว ซึ่งจะช่วยลดข้อความแจ้งที่ซ้ำกันและการป้อนรหัสผ่านด้วยตนเอง
  • ความต่อเนื่องของพาสคีย์: นักพัฒนาแอปสามารถกำหนดขอบเขต RP ID ของพาสคีย์โดยตรงไปยัง โดเมนที่จดทะเบียนได้ ซึ่งจะขยายการรองรับพาสคีย์ไปยังโดเมนย่อยที่เชื่อมโยงทั้งหมดได้ทันที ในกรณีนี้ รหัส RP ของ brand.example จะ ใช้ได้ทั้งที่ www.brand.example และ service.brand.example
  • การแชร์เซสชันที่ง่ายดาย: การรวมโครงสร้างโดเมน ช่วยให้แชร์เซสชันเดียวได้โดยใช้คุกกี้ไวลด์การ์ด (เช่น กำหนดขอบเขตคุกกี้เป็น Domain=brand.example)
• ข้อเสีย:
  • ข้อจำกัดด้านการสร้างแบรนด์และการย้ายข้อมูล: วิธีนี้อาจทำให้เกิดข้อจำกัดด้านการสร้างแบรนด์หากองค์กรกำหนดให้ใช้โดเมนระดับบนสุดที่แตกต่างกัน การย้ายข้อมูลมีความซับซ้อนและต้องมีการจัดการการเปลี่ยนเส้นทาง HTTP อย่างรอบคอบ รวมถึงการแก้ไขการกำหนดค่าแบบข้ามต้นทางเดิมอย่างครอบคลุม

การรวมโดเมนย่อยไว้ภายใต้โดเมนรากทั่วไป

บทสรุป

หากต้องการให้ข้อมูลประจำตัวมีความต่อเนื่อง คุณต้องเปลี่ยนจากการผสานรวมการลงชื่อเข้าใช้เฉพาะกิจ ไปใช้มาตรฐานการตรวจสอบสิทธิ์ที่กำหนดไว้ การประเมินข้อจำกัดทางธุรกิจเทียบกับแนวทางปฏิบัติที่กำหนดไว้เหล่านี้ เช่น สหพันธรัฐ การรวมโดเมน iframe หรือข้อมูลเมตา จะช่วยลดความขัดแย้งด้าน UX และปรับปรุงการตรวจสอบสิทธิ์ในระบบนิเวศของคุณได้

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อที่เกี่ยวข้อง โปรดติดตามบล็อกของเราและสำรวจแหล่งข้อมูลเพิ่มเติม ที่พอร์ทัลข้อมูลประจำตัวของ Chrome