ใน WebAuthn และพาสคีย์ รหัสผู้ให้บริการ (RP ID) จะระบุขอบเขต ของข้อมูลเข้าสู่ระบบตามชื่อโดเมน เมื่อสร้างพาสคีย์ เบราว์เซอร์จะเชื่อมโยงพาสคีย์กับรหัส RP ที่เฉพาะเจาะจง จากนั้นเบราว์เซอร์จะป้องกันการใช้พาสคีย์ดังกล่าวในโดเมนที่ไม่ตรงกันหรือไม่อยู่ในขอบเขตของรหัสนั้น การกำหนด RP ID อย่างถูกต้องจะช่วยให้มั่นใจได้ถึงประสบการณ์การใช้งานพาสคีย์ที่ราบรื่นในโดเมนย่อย ต้นทางข้ามเว็บไซต์ และแอปบนอุปกรณ์เคลื่อนที่ของบุคคลที่หนึ่ง
ข้อมูลเบื้องต้นเกี่ยวกับรหัส RP
รหัส Relying Party (RP ID) คือสตริงที่ไม่ซ้ำกันซึ่งระบุบริการหรือเว็บไซต์ของคุณ รหัส RP ต้องเป็นสตริงโดเมน โดยอาจเป็นชื่อโฮสต์ปัจจุบันที่แน่นอน หรือโดเมนหลักที่กว้างกว่าก็ได้ หากเป็น eTLD+1 ขึ้นไป คุณไม่สามารถใช้ที่อยู่ IP และคำต่อท้ายสาธารณะ (eTLD) เป็น รหัส RP
เช่น หากโฮสต์เซิร์ฟเวอร์ที่ https://www.example.com คุณจะใช้ example.com หรือ www.example.com เป็นรหัส RP ได้ ทั้งนี้ขึ้นอยู่กับความต้องการเฉพาะ
ตารางต่อไปนี้แสดงตัวอย่างรหัส RP ที่อนุญาตโดยขึ้นอยู่กับโฮสต์ต้นทาง
| โฮสต์ต้นทาง | รหัส RP ที่อนุญาต (eTLD+1) |
|---|---|
https://login.example.com |
example.com หรือ login.example.com |
https://example.com:8080 |
example.com (ไม่รวมหมายเลขพอร์ต) |
https://mobile.example.co.jp |
example.co.jp หรือ mobile.example.co.jp |
https://sub.project.org.uk |
project.org.uk หรือ sub.project.org.uk |
https://user.github.io |
user.github.io (github.io เป็น eTLD) |
https://myapp.pages.dev |
myapp.pages.dev (pages.dev เป็น eTLD) |
http://localhost |
localhost (ข้อยกเว้นสำหรับข้อกำหนด HTTPS) |
เบราว์เซอร์จะเชื่อมโยงพาสคีย์กับรหัส RP โดยใช้การเข้ารหัสเมื่อคุณสร้างพาสคีย์ หากต้องการใช้ข้อมูลเข้าสู่ระบบ ต้นทางของคำขอการตรวจสอบสิทธิ์ต้องตรงกับ RP ID นั้น
เมื่อใช้ eTLD+1 เป็นรหัส RP พาสคีย์จะใช้ได้ในโดเมนย่อยที่เกี่ยวข้อง
เช่น รหัส RP ของ example.com ใช้ได้กับ
https://login.example.com และ https://shop.example.com RP
ID ที่เฉพาะเจาะจงมากขึ้น เช่น login.example.com จะใช้ได้ในต้นทางที่ตรงกัน แต่ใช้ไม่ได้ใน https://shop.example.com
รหัส RP ในบริบทข้ามเว็บไซต์
หากบริการของคุณครอบคลุม eTLD+1 หลายรายการ (เช่น example.com และ
example.co.jp) จะเป็นการกำหนดค่าข้ามเว็บไซต์ รหัส RP มาตรฐานไม่รองรับการตั้งค่าข้ามเว็บไซต์
หากต้องการแชร์พาสคีย์ระหว่างเว็บไซต์ที่แตกต่างกัน ให้ใช้คำขอต้นทางที่เกี่ยวข้อง (ROR) ) ROR ช่วยให้คุณแชร์พาสคีย์ ระหว่างเว็บไซต์ที่แตกต่างกันได้เนื่องจากไคลเอ็นต์ (เบราว์เซอร์) จะจดจำต้นทางที่แตกต่างกัน เป็นส่วนหนึ่งของบริการเชิงตรรกะเดียวกัน
ข้อกำหนดสำหรับ ROR
- เลือกรหัส RP 1 รายการ: คุณต้องเลือกรหัส RP 1 รายการและใช้รหัสดังกล่าวในเว็บไซต์ทั้งหมด
- โฮสต์ไฟล์การกำหนดค่า: โดเมนรหัส RP หลักต้องโฮสต์ไฟล์การกำหนดค่าที่
/.well-known/webauthnซึ่งแสดงรายการต้นทางที่ได้รับอนุญาต - รักษาความสอดคล้องกัน: แม้ว่าผู้ใช้จะอยู่ใน
https://www.example.co.jpแต่rpIdในการเรียก WebAuthn ต้องเป็นรายการหลัก (เช่นexample.com) ทั้งในตอนสร้างและตอนตรวจสอบสิทธิ์
ตัวอย่าง ROR สำหรับรหัส RP example.com: https://example.com/.well-known/webauthn
{
"origins": [
"https://www.example.co.jp",
"https://shop.example"
]
}
ดูข้อมูลเพิ่มเติมเกี่ยวกับรายละเอียดการติดตั้งใช้งานคำขอแหล่งที่มาที่เกี่ยวข้องได้ที่ อนุญาตให้ใช้รหัสผ่านแบบพาสคีย์ซ้ำในเว็บไซต์ของคุณด้วยคำขอแหล่งที่มาที่เกี่ยวข้อง
รหัสของ RP ในแอปบนอุปกรณ์เคลื่อนที่
แอปพลิเคชันบนอุปกรณ์เคลื่อนที่สามารถใช้พาสคีย์ได้โดยการเชื่อมโยงกับโดเมนเว็บ คุณต้อง โฮสต์ไฟล์การยืนยันในเซิร์ฟเวอร์เพื่อสร้างความสัมพันธ์นี้
Android: ลิงก์เนื้อหาดิจิทัล
เครื่องมือจัดการ ข้อมูลเข้าสู่ระบบ ของ Android ต้องมีไฟล์ลิงก์เนื้อหาดิจิทัล (DAL) ในโดเมนรหัส RP เพื่อเชื่อมโยงกับแอป
- การโฮสต์: โฮสต์ไฟล์ที่
https://<RP ID>/.well-known/assetlinks.json - การยืนยัน: ยืนยัน
originในclientDataJSONสำหรับ Android ค่านี้ คือสตริง เช่นandroid:apk-key-hash:<hash>
ตัวอย่าง DAL สำหรับรหัส RP example.com (โฮสต์ที่
https://example.com/.well-known/assetlinks.json)
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.google.credentialmanager.sample",
"sha256_cert_fingerprints": [
"4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
]
}
}
]
ดูข้อมูลเพิ่มเติมได้ที่กำหนดค่าลิงก์เนื้อหาดิจิทัลระหว่างแอปกับเว็บไซต์
iOS: โดเมนที่เชื่อมโยง
แพลตฟอร์ม Apple ต้องมีไฟล์ apple-app-site-association (AASA) ในโดเมน RP ID
เพื่อเชื่อมโยงกับแอป
- ไฟล์ AASA: Host
https://<RP_ID>/.well-known/apple-app-site-association - การให้สิทธิ์: เพิ่ม
webcredentials:<app info>ลงในการให้สิทธิ์ของแอป
ตัวอย่าง AASA สำหรับรหัสของ RP example.com:
https://example.com/.well-known/apple-app-site-association:
{
"webcredentials":
{
"apps": ["EXAMPLE123.com.example.passkey"]
}
}
ดูข้อมูลเพิ่มเติมได้ที่การเชื่อมต่อกับบริการด้วยพาสคีย์ ในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ของ Apple
สรุป
โดยรหัส RP จะกำหนดตำแหน่งที่ผู้ใช้เข้าถึงพาสคีย์ โปรดคำนึงถึงประเด็นต่อไปนี้ขณะติดตั้งใช้งาน
- ลำดับชั้นและโดเมนย่อย: รหัส RP ต้องเป็นสตริงโดเมน (eTLD+1 หรือสูงกว่า) การใช้โดเมนที่กว้างขึ้น เช่น
example.comจะช่วยให้พาสคีย์ทำงานในโดเมนย่อยทั้งหมดได้ (เช่นlogin.example.comและshop.example.com) - โซลูชันข้ามเว็บไซต์: ใช้คำขอต้นทางที่เกี่ยวข้อง (ROR) สำหรับบริการ
ที่ครอบคลุม eTLD+1 หลายรายการ โดยต้องใช้รหัส RP 1 รายการและไฟล์กำหนดค่า
ที่
/.well-known/webauthn - การผสานรวมกับอุปกรณ์เคลื่อนที่: สร้างความสัมพันธ์ที่ได้รับการยืนยันระหว่างเว็บไซต์กับแอปบนอุปกรณ์เคลื่อนที่โดยใช้ไฟล์ Digital Asset Links (DAL) ที่
/.well-known/assetlinks.jsonสำหรับ Android และไฟล์ apple-app-site-association (AASA) ที่/.well-known/apple-app-site-associationสำหรับ iOS