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

Maud Nalpas

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

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

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

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

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

โซลูชัน

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

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

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

หากเบราว์เซอร์ไม่รองรับคำขอต้นทางที่เกี่ยวข้อง ระบบจะแสดงข้อผิดพลาด SecurityError

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

Chrome และ Safari รองรับคำขอต้นทางที่เกี่ยวข้อง ณ เดือนมกราคม 2026 Firefox ยังคงพิจารณาฟีเจอร์นี้อยู่ คุณติดตามสถานะได้ในปัญหาเกี่ยวกับจุดยืนด้านมาตรฐานของ Mozilla

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

สาธิต

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

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

  • คุณสามารถสร้างพาสคีย์และตรวจสอบสิทธิ์ด้วยพาสคีย์ดังกล่าวใน ror-2 ได้สำเร็จ แม้ว่า RP ID จะเป็น 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 จะป้อนข้อมูลเข้าสู่ระบบโดยอัตโนมัติด้วย

ดูรหัส:

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

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

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

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

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

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

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

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

ขั้นตอนที่ 3: แสดง JSON .well-known/webauthn ใน 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);
});

ในที่นี้ เราใช้ res.json แบบด่วน ซึ่งตั้งค่า content-type ('application/json') ที่ถูกต้องไว้แล้ว

ขั้นตอนที่ 4: ระบุรหัส RP ใน site-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 ให้ใช้ Digital Asset Links Safari มีระบบที่แตกต่างออกไป

บทบาทของ Credential Manager และ User Agent

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