ปัญหาที่คำขอต้นทางที่เกี่ยวข้องช่วยแก้ปัญหา
พาสคีย์จะเชื่อมโยงกับเว็บไซต์หนึ่งๆ เท่านั้น และใช้เพื่อลงชื่อเข้าใช้เว็บไซต์ที่สร้างพาสคีย์นั้นไว้ได้เท่านั้น
ซึ่งระบุไว้ในรหัสบุคคลที่เชื่อถือ (รหัส 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
ดูรหัส
- ดูไฟล์
./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
ใช้ 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: ลิงก์เนื้อหาดิจิทัล ดูข้อมูลเพิ่มเติมได้ที่เพิ่มการรองรับ Digital Asset Link
- ใน Safari ให้ทำดังนี้ โดเมนที่เชื่อมโยง
แชร์รหัสผ่านในเว็บไซต์ต่างๆ
คำขอต้นทางที่เกี่ยวข้องช่วยให้ผู้ใช้ใช้พาสคีย์ซ้ำในเว็บไซต์ต่างๆ ได้ โซลูชันการแชร์รหัสผ่านในเว็บไซต์ต่างๆ จะแตกต่างกันไปในแต่ละเครื่องมือจัดการรหัสผ่าน สำหรับเครื่องมือจัดการรหัสผ่านบน Google ให้ใช้ลิงก์ชิ้นงานดิจิทัล Safari มีระบบอื่น
บทบาทของเครื่องมือจัดการข้อมูลเข้าสู่ระบบและ User Agent
การดำเนินการนี้อยู่นอกเหนือขอบเขตของคุณในฐานะนักพัฒนาเว็บไซต์ แต่โปรดทราบว่าในระยะยาว รหัส RP ไม่ควรเป็นแนวคิดที่ผู้ใช้มองเห็นใน User Agent หรือเครื่องมือจัดการข้อมูลเข้าสู่ระบบที่ผู้ใช้ใช้ แต่ตัวแทนผู้ใช้และเครื่องมือจัดการข้อมูลเข้าสู่ระบบควรแสดงตำแหน่งที่มีการใช้ข้อมูลเข้าสู่ระบบของผู้ใช้ การเปลี่ยนแปลงนี้ต้องใช้เวลาในการนำมาใช้งาน ทางออกชั่วคราวคือแสดงทั้งเว็บไซต์ปัจจุบันและเว็บไซต์การลงทะเบียนเดิม