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

Maud Nalpas
Maud Nalpas

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

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

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

สาธิต

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

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

  • คุณสร้างพาสคีย์และตรวจสอบสิทธิ์ด้วยพาสคีย์ใน ror-2 ได้สำเร็จ แม้ว่ารหัส RP ของ ror-2 จะเป็น 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 ใช้ site-1.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: แสดง .well-known/webauthn JSON ใน 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 ที่ต้องการใน 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 ให้ใช้ลิงก์ชิ้นงานดิจิทัล Safari มีระบบอื่น

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

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