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

Maud Nalpas

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

ซึ่งระบุไว้ในรหัสของ Relying Party (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 ก็ควรแสดงไฟล์ต่อไปนี้ ที่ 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

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

ตั้งค่าคำขอที่เกี่ยวข้องกับต้นทาง

การสาธิตต่อไปนี้ใช้ 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 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

ดูโค้ด

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

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

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

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

ก่อนอื่น ให้กำหนดค่า site-1.com เพื่อให้ site-2.com ใช้เป็น รหัส RP ได้ โดยสร้างไฟล์ 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

เช่น ใน Express

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

การแก้ปัญหา

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

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

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

• ใน Chrome: Digital Asset Links ดูข้อมูลเพิ่มเติมได้ที่ เพิ่มการรองรับ Digital Asset Links
• ใน Safari ให้ทำดังนี้ โดเมนที่เชื่อมโยง

แชร์รหัสผ่านในเว็บไซต์ต่างๆ

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

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

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