แก้ปัญหา "คำขอจากต้นทางที่เกี่ยวข้อง" ช่วยแก้ปัญหา
พาสคีย์จะผูกกับเว็บไซต์ใดเว็บไซต์หนึ่งโดยเฉพาะ และจะใช้ได้เฉพาะการลงชื่อเข้าใช้ในเว็บไซต์ที่สร้างขึ้นเท่านั้น
ข้อมูลนี้ระบุไว้ในฝ่ายที่มีอำนาจ
รหัส (รหัส RP) ซึ่งสำหรับพาสคีย์ที่สร้างขึ้นสำหรับโดเมน example.com อาจเป็น www.example.com หรือ example.com
ขณะที่รหัส RP ป้องกันไม่ให้ใช้พาสคีย์เป็นข้อมูลรับรองเดียวสำหรับ ตรวจสอบสิทธิ์จากทุกที่ จึงก่อให้เกิดปัญหากับ
- เว็บไซต์ที่มีหลายโดเมน: ผู้ใช้ไม่สามารถใช้พาสคีย์เดียวกันเพื่อ
ลงชื่อเข้าใช้ในโดเมนเฉพาะประเทศต่างๆ (ตัวอย่างเช่น
example.comและexample.co.uk) จัดการโดยบริษัทเดียวกัน - โดเมนที่มีแบรนด์: ผู้ใช้จะใช้ข้อมูลเข้าสู่ระบบเดียวกันในเว็บไซต์ต่างๆ ไม่ได้
โดเมนต่างๆ ที่ใช้โดยแบรนด์เดียว (เช่น
acme.comและacmerewards.com) - แอปบนอุปกรณ์เคลื่อนที่: แอปบนอุปกรณ์เคลื่อนที่มักจะไม่มีโดเมนของตัวเอง จึงทำให้ การจัดการข้อมูลเข้าสู่ระบบเป็นเรื่องที่ท้าทาย
มีวิธีแก้ปัญหาตามการรวมศูนย์ข้อมูลประจำตัว และวิธีอื่นๆ ที่ แต่ใช้ได้ยากในบางกรณี ข้อเสนอของคำขอจากต้นทางที่เกี่ยวข้อง โซลูชัน
โซลูชัน
ด้วย คำขอต้นทางที่เกี่ยวข้อง เว็บไซต์สามารถระบุต้นทางที่ได้รับอนุญาตให้ใช้รหัส 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
ดูโค้ด
- ดูไฟล์
./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: แสดง 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);
});
เราใช้ 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: เนื้อหาดิจิทัล ลิงก์ ดูข้อมูลเพิ่มเติมที่ เพิ่มการรองรับลิงก์เนื้อหาดิจิทัล
- ใน Safari โดเมนที่เชื่อมโยง
แชร์รหัสผ่านระหว่างเว็บไซต์
คำขอต้นทางที่เกี่ยวข้องอนุญาตให้ผู้ใช้ใช้พาสคีย์ซ้ำในเว็บไซต์ต่างๆ ได้ โซลูชันสำหรับการแชร์รหัสผ่านข้ามเว็บไซต์จะแตกต่างกันไปสำหรับเครื่องมือจัดการรหัสผ่านแต่ละคน สำหรับเครื่องมือจัดการรหัสผ่านบน Google ให้ใช้ลิงก์เนื้อหาดิจิทัล Safari มีระบบอื่น
บทบาทของเครื่องมือจัดการข้อมูลเข้าสู่ระบบและ User Agent
ซึ่งอยู่นอกเหนือขอบเขตของคุณในฐานะนักพัฒนาไซต์ แต่โปรดทราบว่าเมื่อนานมาแล้ว รหัส RP ไม่ควรเป็นแนวคิดที่ผู้ใช้มองเห็นได้ใน User Agent หรือ เครื่องมือจัดการข้อมูลเข้าสู่ระบบที่ผู้ใช้ของคุณใช้อยู่ User Agent และข้อมูลเข้าสู่ระบบแทน ผู้จัดการควรแสดงให้ผู้ใช้เห็นสถานที่ที่เคยใช้ข้อมูลเข้าสู่ระบบของพวกเขา การเปลี่ยนแปลงนี้ จะต้องใช้เวลาเท่าใด วิธีแก้ปัญหาชั่วคราวคือการแสดงทั้ง เว็บไซต์ปัจจุบันและเว็บไซต์การลงทะเบียนเดิม