อนุญาตให้ใช้พาสคีย์ซ้ำในเว็บไซต์ต่างๆ ด้วยคำขอจากต้นทางที่เกี่ยวข้อง

Maud Nalpas
Maud Nalpas

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

ข้อมูลนี้ระบุไว้ในฝ่ายที่มีอำนาจ รหัส (รหัส RP) ซึ่งสำหรับพาสคีย์ที่สร้างขึ้นสำหรับโดเมน example.com อาจเป็น www.example.com หรือ example.com

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

  • เว็บไซต์ที่มีหลายโดเมน: ผู้ใช้ไม่สามารถใช้พาสคีย์เดียวกันเพื่อ ลงชื่อเข้าใช้ในโดเมนเฉพาะประเทศต่างๆ (ตัวอย่างเช่น example.com และ example.co.uk) จัดการโดยบริษัทเดียวกัน
  • โดเมนที่มีแบรนด์: ผู้ใช้จะใช้ข้อมูลเข้าสู่ระบบเดียวกันในเว็บไซต์ต่างๆ ไม่ได้ โดเมนต่างๆ ที่ใช้โดยแบรนด์เดียว (เช่น acme.com และ acmerewards.com)
  • แอปบนอุปกรณ์เคลื่อนที่: แอปบนอุปกรณ์เคลื่อนที่มักจะไม่มีโดเมนของตัวเอง จึงทำให้ การจัดการข้อมูลเข้าสู่ระบบเป็นเรื่องที่ท้าทาย

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

โซลูชัน

ด้วย คำขอต้นทางที่เกี่ยวข้อง เว็บไซต์สามารถระบุต้นทางที่ได้รับอนุญาตให้ใช้รหัส RP ของตน

วิธีนี้ช่วยให้ผู้ใช้นำพาสคีย์เดียวกันมาใช้ซ้ำได้ในหลายๆ เว็บไซต์ที่คุณดำเนินการ

หากต้องการใช้คำขอต้นทางที่เกี่ยวข้อง คุณต้องแสดงไฟล์ JSON พิเศษที่ URL เฉพาะ https://{RP ID}/.well-known/webauthn หาก example.com ต้องการ อนุญาตให้ต้นทางเพิ่มเติมใช้เป็นรหัส RP ได้ ซึ่งควรแสดงข้อมูลต่อไปนี้ ไฟล์ที่ https://example.com/.well-known/webauthn:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

ครั้งถัดไปที่เว็บไซต์เหล่านี้เรียกใช้การสร้างพาสคีย์ (navigator.credentials.create) หรือการตรวจสอบสิทธิ์ (navigator.credentials.get) ที่ใช้ example.com เป็นรหัส RP เบราว์เซอร์จะเห็นรหัส RP ที่ ต้นทางที่ส่งคำขอไม่ตรงกัน หากเบราว์เซอร์รองรับต้นทางที่เกี่ยวข้อง คำขอจะมองหา webauthn ไฟล์ที่ https://{RP ID}/.well-known/webauthn หากมีไฟล์อยู่ เบราว์เซอร์จะตรวจสอบว่าต้นทางที่ส่งคำขออยู่ในรายการที่อนุญาตหรือไม่ ในกรณีนี้ ระบบจะดำเนินการต่อเพื่อสร้างพาสคีย์หรือขั้นตอนการตรวจสอบสิทธิ์ หากเบราว์เซอร์ไม่รองรับคำขอต้นทางที่เกี่ยวข้อง จะมีการส่ง SecurityError

การสนับสนุนเบราว์เซอร์

  • Chrome: รองรับตั้งแต่ Chrome 128
  • Safari: รองรับตั้งแต่ macOS 15 เบต้า 3 และ iOS 18 เบต้า 3 บนอุปกรณ์เคลื่อนที่
  • Firefox ตำแหน่งรอ

การสาธิตต่อไปนี้ใช้ตัวอย่างเว็บไซต์ 2 แห่ง ได้แก่ https://ror-1.glitch.me และ https://ror-2.glitch.me
หากต้องการให้ผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์เดียวกันในเว็บไซต์ทั้ง 2 แห่งนี้ ระบบจะใช้คำขอต้นทางที่เกี่ยวข้องเพื่ออนุญาตให้ ror-2.glitch.me ใช้ ror-1.glitch.me เป็นรหัส RP ของตน

สาธิต

https://ror-2.glitch.me ใช้คำขอต้นทางที่เกี่ยวข้องเพื่อใช้ ror-1.glitch.me เป็นรหัส RP ดังนั้นทั้ง ror-1 และ ror-2 จึงใช้ ror-1.glitch.me เป็นรหัส RP เมื่อสร้างพาสคีย์หรือตรวจสอบสิทธิ์ด้วยรหัสดังกล่าว
นอกจากนี้ เรายังได้ติดตั้งฐานข้อมูลพาสคีย์ที่แชร์ในเว็บไซต์เหล่านี้ด้วย

ตรวจสอบประสบการณ์ของผู้ใช้ต่อไปนี้

  • คุณสามารถสร้างพาสคีย์และตรวจสอบสิทธิ์ด้วยพาสคีย์ดังกล่าวได้ใน ror-2 แม้ว่ารหัส RP ของพาสคีย์จะเป็น ror-1 (ไม่ใช่ ror-2)
  • เมื่อสร้างพาสคีย์ใน ror-1 หรือ ror-2 แล้ว คุณจะตรวจสอบสิทธิ์ด้วยพาสคีย์ดังกล่าวทั้งใน ror-1 และ ror-2 ได้ เนื่องจาก ror-2 ระบุ ror-1 เป็นรหัส RP การสร้างพาสคีย์หรือคำขอการตรวจสอบสิทธิ์จากเว็บไซต์ใดๆ เหล่านี้จะเหมือนกับการส่งคำขอใน ror-1 รหัส RP เป็นเพียงสิ่งเดียวที่เชื่อมโยงคำขอกับต้นทาง
  • เมื่อสร้างพาสคีย์ใน ror-1 หรือ ror-2 แล้ว Chrome จะป้อนข้อความอัตโนมัติลงในทั้ง ror-1 และ ror-2 ได้
  • ข้อมูลเข้าสู่ระบบที่สร้างขึ้นในเว็บไซต์เหล่านี้จะมีรหัส RP เป็น ror-1
Chrome จะป้อนข้อความอัตโนมัติในทั้ง 2 เว็บไซต์
คำขอจากต้นทางที่เกี่ยวข้องช่วยให้ผู้ใช้ใช้ข้อมูลเข้าสู่ระบบของพาสคีย์เดียวกันได้ทั้งใน ror-1 และ ror-2 Chrome จะป้อนข้อมูลเข้าสู่ระบบโดยอัตโนมัติด้วย

ดูโค้ด

  • ดูไฟล์ ./well-known/webauthn ที่ตั้งค่าใน ror-1 Codebase
  • ดู RP_ID_ROR รายการใน ror-2 Codebase

ขั้นตอนที่ 1: ใช้ฐานข้อมูลบัญชีที่ใช้ร่วมกัน

ถ้าคุณต้องการให้ผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์เดียวกันได้ site-1 และ site-2 ใช้ฐานข้อมูลบัญชีที่แชร์กัน สองเว็บไซต์

ขั้นตอนที่ 2: ตั้งค่าไฟล์ JSON .well-known/webauthn ใน site-1

ก่อนอื่น ให้กำหนดค่า site-1.com เพื่อให้ site-2.com สามารถใช้เป็น รหัส RP ซึ่งทำได้โดยสร้างไฟล์ JSON ของ webauthn ดังนี้

{
    "origins": [
        "https://site-2.com"
    ]
}

ออบเจ็กต์ JSON ต้องมีคีย์ที่มีชื่อต้นทางซึ่งมีค่าเป็นอาร์เรย์ สตริงอย่างน้อย 1 สตริงที่มีต้นทางเว็บ

ข้อจำกัดสำคัญ: ป้ายกำกับสูงสุด 5 รายการ

ระบบจะประมวลผลแต่ละองค์ประกอบของรายการนี้เพื่อดึง eTLD + ป้ายกำกับ 1 รายการ ตัวอย่างเช่น eTLD + 1 ป้ายกำกับของ example.co.uk และ example.de มีทั้ง example แต่ป้ายกำกับ eTLD + 1 ของ example-rewards.com คือ example-rewards ใน Chrome จำนวนป้ายกำกับสูงสุดคือ 5 รายการ

ขั้นตอนที่ 3: แสดง .well-known/webauthn JSON ใน site-1

จากนั้นแสดงไฟล์ JSON ภายใต้ site-1.com/.well-known/webauthn

ตัวอย่างเช่น ในลักษณะด่วน

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

เราใช้ Express res.json ซึ่งตั้งค่าแอตทริบิวต์ ถูกต้อง content-type ('application/json');

ขั้นตอนที่ 4: ระบุรหัส RP ที่ต้องการในเว็บไซต์-2

ในโค้ดฐาน site-2 ให้ตั้งค่า site-1.com เป็นรหัส RP ในทุกที่ที่จำเป็น ดังนี้

  • เมื่อสร้างข้อมูลเข้าสู่ระบบ:
    • ตั้ง site-1.com เป็นรหัส RP ในการสร้างข้อมูลเข้าสู่ระบบ options ซึ่งส่งไปยัง navigator.credentials.create และมักจะสร้างขึ้นจากฝั่งเซิร์ฟเวอร์
    • ตั้งค่า site-1.com เป็นรหัส RP ที่คาดไว้เมื่อเรียกใช้ข้อมูลเข้าสู่ระบบ การยืนยันก่อนที่จะบันทึกลงในฐานข้อมูล
  • ขณะตรวจสอบสิทธิ์:
    • ตั้งค่า site-1.com เป็นรหัส RP ในการตรวจสอบสิทธิ์ options ที่ส่งไปยังการเรียกฟรอนท์เอนด์ navigator.credentials.get และ ฝั่งเซิร์ฟเวอร์ที่มักสร้างขึ้น
    • ตั้งค่า site-1.com เป็นรหัส RP ที่คาดไว้ว่าจะได้รับการยืนยันใน เซิร์ฟเวอร์ของคุณ ขณะที่คุณเรียกใช้การยืนยันข้อมูลเข้าสู่ระบบก่อนการตรวจสอบสิทธิ์ผู้ใช้

การแก้ปัญหา

ป๊อปอัปข้อความแสดงข้อผิดพลาดใน Chrome
ข้อความแสดงข้อผิดพลาดใน Chrome เมื่อสร้างข้อมูลเข้าสู่ระบบ ระบบจะแสดงข้อผิดพลาดนี้หากไม่พบไฟล์ ".well-known/webauthn" ที่ "https://{RP ID}/.well-known/webauthn"
ป๊อปอัปข้อความแสดงข้อผิดพลาดใน Chrome
ข้อความแสดงข้อผิดพลาดใน Chrome เมื่อสร้างข้อมูลเข้าสู่ระบบ ระบบจะแสดงข้อผิดพลาดนี้หากพบไฟล์ ".well-known/webauthn" แต่ไม่แสดงต้นทางที่คุณพยายามสร้างข้อมูลเข้าสู่ระบบ

ข้อควรพิจารณาอื่นๆ

แชร์พาสคีย์ในเว็บไซต์และแอปบนอุปกรณ์เคลื่อนที่

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

แชร์รหัสผ่านข้ามเว็บไซต์

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

บทบาทของเครื่องมือจัดการข้อมูลเข้าสู่ระบบและ User Agent

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