ลงชื่อเข้าใช้ด้วยพาสคีย์ผ่านการป้อนแบบฟอร์มอัตโนมัติ

สร้างประสบการณ์การลงชื่อเข้าใช้ที่ใช้ประโยชน์จากพาสคีย์ในขณะที่ยังรองรับ ผู้ใช้รหัสผ่านที่มีอยู่

Eiji Kitamura

คู่มือนี้อธิบายวิธีใช้การป้อนข้อความอัตโนมัติในแบบฟอร์มเพื่อให้ผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์ควบคู่ไปกับรหัสผ่าน การใช้การป้อนข้อความอัตโนมัติในแบบฟอร์มจะช่วยสร้างประสบการณ์การลงชื่อเข้าใช้แบบรวม ซึ่งจะช่วยลดความซับซ้อน ในการเปลี่ยนจากรหัสผ่านไปใช้วิธีการตรวจสอบสิทธิ์ด้วยพาสคีย์ที่ปลอดภัยและใช้งานง่ายยิ่งขึ้น

ดูวิธีใช้ UI แบบมีเงื่อนไขของ WebAuthn เพื่อรองรับทั้งผู้ใช้พาสคีย์และผู้ใช้รหัสผ่านโดยลดอุปสรรคในแบบฟอร์มลงชื่อเข้าใช้ที่มีอยู่ให้เหลือน้อยที่สุด

เหตุใดจึงควรใช้การป้อนข้อความอัตโนมัติในแบบฟอร์มเพื่อลงชื่อเข้าใช้ด้วยพาสคีย์

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

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

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

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

ใช้ UI ตามเงื่อนไข

หากต้องการรองรับทั้งผู้ใช้พาสคีย์และรหัสผ่านอย่างมีประสิทธิภาพ ให้รวมพาสคีย์ไว้ในคำแนะนำการป้อนอัตโนมัติของแบบฟอร์ม แนวทางนี้ ใช้UI แบบมีเงื่อนไข ซึ่งเป็นฟีเจอร์ของมาตรฐาน WebAuthn

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

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

วิธีการทำงานของการตรวจสอบสิทธิ์ด้วยพาสคีย์

หากต้องการตรวจสอบสิทธิ์ด้วยพาสคีย์ ให้ใช้ WebAuthn API

องค์ประกอบ 4 อย่างในขั้นตอนการตรวจสอบสิทธิ์ด้วยพาสคีย์มีดังนี้

• แบ็กเอนด์: จัดเก็บรายละเอียดบัญชีผู้ใช้ รวมถึงคีย์สาธารณะ
• ฟรอนท์เอนด์: สื่อสารกับเบราว์เซอร์และดึงข้อมูลที่จำเป็น จากแบ็กเอนด์
• เบราว์เซอร์: เรียกใช้ JavaScript และโต้ตอบกับ WebAuthn API
• ผู้ให้บริการพาสคีย์: สร้างและจัดเก็บพาสคีย์ โดยปกติแล้วจะเป็น เครื่องมือจัดการรหัสผ่าน เช่น เครื่องมือจัดการรหัสผ่านบน Google หรือคีย์ความปลอดภัย

กระบวนการตรวจสอบสิทธิ์ด้วยพาสคีย์เป็นไปตามขั้นตอนต่อไปนี้

1. ผู้ใช้ไปที่หน้าลงชื่อเข้าใช้ และส่วนหน้าจะขอการท้าทายการตรวจสอบสิทธิ์จากส่วนหลัง
2. แบ็กเอนด์จะสร้างและแสดงคำท้า WebAuthn ที่เชื่อมโยง กับบัญชีของผู้ใช้
3. ส่วนหน้าเรียกใช้ navigator.credentials.get() พร้อมกับคำท้า เพื่อเริ่มการตรวจสอบสิทธิ์โดยใช้เบราว์เซอร์
4. เบราว์เซอร์ที่โต้ตอบกับผู้ให้บริการพาสคีย์จะแจ้งให้ผู้ใช้เลือกพาสคีย์ (มักใช้กล่องโต้ตอบการป้อนข้อความอัตโนมัติที่ทริกเกอร์โดยการโฟกัสช่องลงชื่อเข้าใช้) และยืนยันตัวตนโดยใช้การล็อกหน้าจอของอุปกรณ์หรือไบโอเมตริก
5. หลังจากยืนยันตัวตนผู้ใช้สำเร็จแล้ว ผู้ให้บริการพาสคีย์จะลงนามใน แชลเลนจ์ และเบราว์เซอร์จะส่งคืนข้อมูลเข้าสู่ระบบคีย์สาธารณะที่ได้ (รวมถึงลายเซ็น) ไปยังส่วนหน้า
6. ส่วนหน้าจะส่งข้อมูลเข้าสู่ระบบนี้ไปยังส่วนหลัง
7. แบ็กเอนด์จะยืนยันลายเซ็นของข้อมูลเข้าสู่ระบบกับคีย์สาธารณะที่ จัดเก็บไว้ของผู้ใช้ หากการยืนยันสำเร็จ แบ็กเอนด์จะลงชื่อเข้าใช้ให้ผู้ใช้

ตรวจสอบสิทธิ์ด้วยพาสคีย์ผ่านการป้อนข้อความอัตโนมัติในแบบฟอร์ม

หากต้องการเริ่มการตรวจสอบสิทธิ์ด้วยพาสคีย์โดยใช้การป้อนข้อความอัตโนมัติในแบบฟอร์ม ให้เรียกใช้ WebAuthn get แบบมีเงื่อนไขเมื่อหน้าลงชื่อเข้าใช้โหลด การเรียกใช้ navigator.credentials.get()นี้มีตัวเลือก mediation: 'conditional'
คำขอแบบมีเงื่อนไขไปยัง API ของ WebAuthn navigator.credentials.get() จะไม่แสดง UI ทันที แต่จะ รอในสถานะรอดำเนินการจนกว่าผู้ใช้จะโต้ตอบกับข้อความแจ้งเติมข้อความอัตโนมัติของช่องชื่อผู้ใช้ หากผู้ใช้เลือกพาสคีย์ เบราว์เซอร์จะแก้ไขสัญญาที่รอดำเนินการ ด้วยข้อมูลเข้าสู่ระบบเพื่อลงชื่อเข้าใช้ผู้ใช้ โดยข้ามการส่งแบบฟอร์มแบบเดิม หากผู้ใช้เลือกใช้รหัสผ่านแทน ระบบจะไม่ดำเนินการตามสัญญา และขั้นตอนการลงชื่อเข้าใช้ด้วยรหัสผ่านมาตรฐานจะดำเนินต่อไปrm จากนั้นหน้าที่รับผิดชอบในการลงชื่อเข้าใช้ของผู้ใช้จะเป็นของหน้าเว็บ

ใส่คำอธิบายประกอบช่องป้อนข้อมูลแบบฟอร์ม

หากต้องการเปิดใช้การป้อนข้อความอัตโนมัติของพาสคีย์ ให้เพิ่มแอตทริบิวต์ autocomplete ลงในช่อง ชื่อผู้ใช้inputของแบบฟอร์ม ระบุทั้ง username และ webauthn เป็นค่าที่คั่นด้วยช่องว่าง

<input type="text" name="username" autocomplete="username webauthn" autofocus>

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

การตรวจหาฟีเจอร์

ก่อนเรียกใช้การเรียก API ของ WebAuthn แบบมีเงื่อนไข ให้ตรวจสอบว่า

• เบราว์เซอร์รองรับ WebAuthn ด้วย PublicKeyCredential

• เบราว์เซอร์รองรับการตรวจหา ความสามารถด้วย PublicKeyCredential.getClientCapabilities()

• เบราว์เซอร์รองรับ UI แบบมีเงื่อนไขของ WebAuthn ที่มี conditionalGet

ข้อมูลโค้ดต่อไปนี้แสดงวิธีตรวจสอบว่าเบราว์เซอร์รองรับฟีเจอร์เหล่านี้หรือไม่

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  // Check if conditional mediation is available.  
  if (capabilities.conditionalGet === true) {
    // The browser supports conditional mediation.
  }
}

ดึงข้อมูลจากแบ็กเอนด์

แบ็กเอนด์ของคุณต้องมีตัวเลือกหลายอย่างให้ฟรอนต์เอนด์เพื่อเริ่มการเรียกใช้ navigator.credentials.get() โดยปกติแล้ว ระบบจะดึงตัวเลือกเหล่านี้เป็นออบเจ็กต์ JSON จากปลายทางในเซิร์ฟเวอร์

พร็อพเพอร์ตี้หลักในออบเจ็กต์ตัวเลือกมีดังนี้

• challenge: คำท้าที่เซิร์ฟเวอร์สร้างขึ้นใน ArrayBuffer (โดยปกติจะเข้ารหัส Base64URL สำหรับการรับส่ง JSON) ซึ่งเป็นสิ่งจำเป็นในการป้องกันการโจมตีแบบรีเพลย์ เซิร์ฟเวอร์ต้องสร้างคำท้าใหม่ทุกครั้งที่มีการพยายามลงชื่อเข้าใช้ และควร ทำให้คำท้าดังกล่าวใช้ไม่ได้หลังจากผ่านไปในระยะเวลาสั้นๆ หรือหากการพยายามลงชื่อเข้าใช้ไม่สำเร็จ
• allowCredentials: อาร์เรย์ของตัวอธิบายข้อมูลเข้าสู่ระบบ ส่งอาร์เรย์ที่ว่างเปล่า ซึ่งจะแจ้ง ให้เบราว์เซอร์แสดงข้อมูลเข้าสู่ระบบทั้งหมดสำหรับ rpId ที่ระบุ

• userVerification: ระบุค่ากำหนดสำหรับการยืนยันผู้ใช้ เช่น การกำหนดให้ใช้การล็อกหน้าจอ อุปกรณ์ ค่าเริ่มต้นและค่าที่แนะนำคือ "preferred" ค่าที่เป็นไปได้ มีดังนี้

  • "required": Authenticator ต้องทำการยืนยันผู้ใช้ (เช่น PIN หรือข้อมูลไบโอเมตริก) การดำเนินการจะล้มเหลวหากดำเนินการยืนยันไม่ได้
  • "preferred": เครื่องมือตรวจสอบพยายามยืนยันผู้ใช้ แต่การดำเนินการ อาจสำเร็จได้โดยไม่ต้องยืนยัน
  • "discouraged": โปรแกรมตรวจสอบสิทธิ์ควรหลีกเลี่ยงการยืนยันผู้ใช้หากเป็นไปได้

• rpId: รหัสผู้ให้บริการที่เกี่ยวข้อง ซึ่งโดยปกติคือโดเมนของเว็บไซต์ (เช่น example.com) ค่านี้ต้องตรงกับrp.idที่ใช้เมื่อสร้างข้อมูลเข้าสู่ระบบพาสคีย์ทุกประการ

เซิร์ฟเวอร์ควรสร้างออบเจ็กต์ตัวเลือกนี้ ArrayBuffer (เช่น challenge) ต้องเข้ารหัส Base64URL สำหรับการส่ง JSON ในส่วนฟรอนท์เอนด์ หลังจากแยกวิเคราะห์ JSON แล้ว ให้ใช้ PublicKeyCredential.parseRequestOptionsFromJSON() เพื่อแปลงออบเจ็กต์ (รวมถึงการถอดรหัสสตริง Base64URL) เป็นรูปแบบที่ navigator.credentials.get() คาดหวัง

ข้อมูลโค้ดต่อไปนี้แสดงวิธีดึงและถอดรหัสข้อมูล ที่จำเป็นในการตรวจสอบสิทธิ์ด้วยพาสคีย์

// Fetch an encoded PubicKeyCredentialRequestOptions from the server.
const _options = await fetch('/webauthn/signinRequest');

// Deserialize and decode the PublicKeyCredentialRequestOptions.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseRequestOptionsFromJSON(decoded_options);
...

เรียกใช้ WebAuthn API ด้วย Flag conditional เพื่อตรวจสอบสิทธิ์ผู้ใช้

เมื่อเตรียมออบเจ็กต์ publicKeyCredentialRequestOptions (เรียกว่า options ในโค้ดตัวอย่างด้านล่าง) แล้ว ให้เรียกใช้ navigator.credentials.get() เพื่อเริ่มการตรวจสอบสิทธิ์ด้วยพาสคีย์แบบมีเงื่อนไข

// To abort a WebAuthn call, instantiate an AbortController.
const abortController = new AbortController();

// Invoke WebAuthn to authenticate with a passkey.
const credential = await navigator.credentials.get({
  publicKey: options,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

พารามิเตอร์หลักสำหรับการเรียกนี้มีดังนี้

• publicKey: นี่ต้องเป็นออบเจ็กต์ publicKeyCredentialRequestOptions (ชื่อ options ในตัวอย่าง) ที่คุณดึงข้อมูลจากเซิร์ฟเวอร์และ ประมวลผลในขั้นตอนก่อนหน้า
• signal: การส่งสัญญาณของ AbortController (เช่น abortController.signal) ช่วยให้คุณยกเลิกคำขอ get() ได้โดยอัตโนมัติ ซึ่งจะเป็นประโยชน์เมื่อคุณต้องการเรียกใช้ WebAuthn อื่น
• mediation: 'conditional': นี่คือแฟล็กที่สำคัญซึ่งทำให้การเรียกใช้ WebAuthn เป็นแบบมีเงื่อนไข ซึ่งจะบอกให้เบราว์เซอร์รอการโต้ตอบของผู้ใช้ กับข้อความแจ้งป้อนข้อความอัตโนมัติ แทนที่จะแสดงกล่องโต้ตอบแบบโมดอล ทันที

ส่งข้อมูลเข้าสู่ระบบคีย์สาธารณะที่ส่งคืนไปยังเซิร์ฟเวอร์ RP

Aหากผู้ใช้เลือกพาสคีย์และยืนยันตัวตนสำเร็จ (เช่น ใช้การล็อกหน้าจอของอุปกรณ์) navigator.credentials.get() Promise จะได้รับการแก้ไข ซึ่งจะแสดงผลออบเจ็กต์ PublicKeyCredential ไปยังส่วนหน้า

ระบบอาจปฏิเสธคำสัญญาด้วยเหตุผลหลายประการ คุณควรจัดการข้อผิดพลาดเหล่านี้ ในโค้ดโดยตรวจสอบพร็อพเพอร์ตี้ name ของออบเจ็กต์ Error ดังนี้

• NotAllowedError: ผู้ใช้ยกเลิกการดำเนินการ หรือไม่ได้เลือกพาสคีย์
• AbortError: การดำเนินการถูกยกเลิก ซึ่งอาจเกิดจากโค้ดของคุณที่ใช้ AbortController
• ข้อยกเว้นอื่นๆ: เกิดข้อผิดพลาดที่ไม่คาดคิด โดยปกติเบราว์เซอร์จะ แสดงกล่องโต้ตอบข้อผิดพลาดต่อผู้ใช้

ออบเจ็กต์ PublicKeyCredential มีพร็อพเพอร์ตี้หลายรายการ พร็อพเพอร์ตี้หลัก ที่เกี่ยวข้องกับการตรวจสอบสิทธิ์มีดังนี้

• id: รหัสที่เข้ารหัส Base64url ของข้อมูลเข้าสู่ระบบพาสคีย์ที่ได้รับการตรวจสอบสิทธิ์
• rawId รหัสข้อมูลเข้าสู่ระบบเวอร์ชัน ArrayBuffer
• response.clientDataJSON: ArrayBuffer ของข้อมูลไคลเอ็นต์ ฟิลด์นี้มีข้อมูล เช่น ชาเลนจ์และต้นทางที่เซิร์ฟเวอร์ต้องยืนยัน
• response.authenticatorData: ArrayBuffer ของข้อมูลเครื่องมือตรวจสอบสิทธิ์ ฟิลด์นี้มีข้อมูล เช่น รหัส RP
• response.signature: ArrayBuffer ที่มีลายเซ็น ค่านี้เป็นหัวใจสำคัญของ ข้อมูลเข้าสู่ระบบ และเซิร์ฟเวอร์ของคุณต้องยืนยันลายเซ็นนี้โดยใช้ คีย์สาธารณะที่จัดเก็บไว้สำหรับข้อมูลเข้าสู่ระบบ
• response.userHandle: ArrayBuffer ที่มีรหัสผู้ใช้ที่ระบุระหว่างการลงทะเบียนพาสคีย์
• authenticatorAttachment: ระบุว่าเครื่องมือตรวจสอบสิทธิ์เป็นส่วนหนึ่งของอุปกรณ์ไคลเอ็นต์ (platform) หรือ ภายนอก (cross-platform) การแนบ cross-platform อาจเกิดขึ้น หาก ผู้ใช้ลงชื่อเข้าใช้ด้วยโทรศัพท์ ในกรณีดังกล่าว ให้พิจารณาแจ้งให้ผู้ใช้สร้างพาสคีย์ ในอุปกรณ์ปัจจุบันเพื่อความสะดวกในอนาคต
• type: ช่องนี้จะตั้งค่าเป็น "public-key" เสมอ

หากต้องการส่งออบเจ็กต์ PublicKeyCredential นี้ไปยังแบ็กเอนด์ ให้เรียกใช้เมธอด .toJSON() ก่อน วิธีนี้จะสร้างข้อมูลเข้าสู่ระบบเวอร์ชันที่แปลงเป็น JSON ได้ ซึ่งจะจัดการการแปลงพร็อพเพอร์ตี้ ArrayBuffer (เช่น rawId, clientDataJSON, authenticatorData, signature และ userHandle) เป็นสตริงที่เข้ารหัส Base64URL ได้อย่างถูกต้อง จากนั้นใช้ JSON.stringify() เพื่อแปลงออบเจ็กต์นี้ เป็นสตริงและส่งในเนื้อหาของคำขอไปยังเซิร์ฟเวอร์

...
// Encode and serialize the PublicKeyCredential.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/signinResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

ยืนยันลายเซ็น

เมื่อเซิร์ฟเวอร์แบ็กเอนด์ได้รับข้อมูลเข้าสู่ระบบคีย์สาธารณะ เซิร์ฟเวอร์จะต้องยืนยัน ความถูกต้องของข้อมูลเข้าสู่ระบบ ซึ่งเกี่ยวข้องกับสิ่งต่อไปนี้

1. กำลังแยกวิเคราะห์ข้อมูลเข้าสู่ระบบ
2. ค้นหาคีย์สาธารณะที่จัดเก็บไว้ซึ่งเชื่อมโยงกับ id ของข้อมูลเข้าสู่ระบบ
3. ยืนยัน signature ที่ได้รับกับคีย์สาธารณะที่จัดเก็บไว้
4. การตรวจสอบข้อมูลอื่นๆ เช่น ชาเลนจ์และต้นทาง

เราขอแนะนำให้ใช้ไลบรารี FIDO/WebAuthn ฝั่งเซิร์ฟเวอร์เพื่อจัดการการดำเนินการเข้ารหัสเหล่านี้อย่างปลอดภัย คุณจะค้นหาไลบรารีโอเพนซอร์สได้ในที่เก็บ awesome-webauthn ของ GitHub

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

ส่งสัญญาณหากไม่พบข้อมูลเข้าสู่ระบบที่ตรงกันในแบ็กเอนด์

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

คุณสามารถใช้วิธี PublicKeyCredential.signalUnknownCredential() ซึ่งเป็นส่วนหนึ่งของ Webauthn Signal API เพื่อแจ้งผู้ให้บริการพาสคีย์ว่ามีการนำข้อมูลเข้าสู่ระบบที่ระบุออกแล้วหรือ ไม่มีอยู่ เรียกใช้เมธอดแบบคงที่นี้ในฝั่งไคลเอ็นต์หากเซิร์ฟเวอร์ระบุ (เช่น ด้วยรหัสสถานะ HTTP ที่เฉพาะเจาะจง เช่น 404) ว่าไม่รู้จักรหัสข้อมูลเข้าสู่ระบบที่แสดง ระบุรหัส RP และรหัสข้อมูลเข้าสู่ระบบที่ไม่รู้จัก ให้กับเมธอดนี้ ผู้ให้บริการพาสคีย์ควรนำพาสคีย์ออกหากรองรับสัญญาณ

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

หลังการตรวจสอบสิทธิ์

เราจะแนะนำขั้นตอนต่างๆ ที่ควรทำตามโดยขึ้นอยู่กับวิธีที่ผู้ใช้ลงชื่อเข้าใช้

หากผู้ใช้ลงชื่อเข้าใช้โดยไม่มีพาสคีย์

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

• อัปเกรดรหัสผ่านเป็นพาสคีย์: ใช้การสร้างแบบมีเงื่อนไข ซึ่งเป็นฟีเจอร์ WebAuthn ที่อนุญาตให้เบราว์เซอร์สร้างพาสคีย์สำหรับ ผู้ใช้โดยอัตโนมัติหลังจากลงชื่อเข้าใช้ด้วยรหัสผ่านสำเร็จ ซึ่งจะช่วยปรับปรุง การใช้พาสคีย์ได้อย่างมากด้วยการลดความซับซ้อนของกระบวนการสร้าง ดูวิธีการทำงาน และวิธีติดตั้งใช้งานที่ช่วยให้ผู้ใช้ใช้พาสคีย์ได้อย่างราบรื่นยิ่งขึ้น
• แจ้งให้สร้างพาสคีย์ด้วยตนเอง: กระตุ้นให้ผู้ใช้สร้างพาสคีย์ ซึ่งจะมีประสิทธิภาพหลังจากที่ผู้ใช้ทำกระบวนการลงชื่อเข้าใช้ที่ซับซ้อนมากขึ้น เช่น การตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) เสร็จแล้ว อย่างไรก็ตาม โปรดหลีกเลี่ยงการแจ้งเตือนมากเกินไป ซึ่งอาจรบกวนประสบการณ์ของผู้ใช้"

ดูวิธีกระตุ้นให้ผู้ใช้สร้างพาสคีย์และดูแนวทางปฏิบัติอื่นๆ ที่ดีได้ที่ตัวอย่างในการสื่อสารเรื่องพาสคีย์กับผู้ใช้

หากผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์

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

กระตุ้นให้สร้างพาสคีย์ใหม่หลังจากการตรวจสอบสิทธิ์ข้ามอุปกรณ์

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

• มีพาสคีย์ แต่ใช้กับผู้ให้บริการพาสคีย์ที่ไม่รองรับระบบปฏิบัติการหรือเบราว์เซอร์ที่ใช้ลงชื่อเข้าใช้
• ผู้ใช้เสียสิทธิ์เข้าถึงผู้ให้บริการพาสคีย์ในอุปกรณ์ที่ใช้ลงชื่อเข้าใช้ แต่ยังมีพาสคีย์ในอุปกรณ์อื่น

ในกรณีนี้ ให้พิจารณาแจ้งให้ผู้ใช้สร้างพาสคีย์ใหม่ใน อุปกรณ์ปัจจุบัน ซึ่งจะช่วยให้ผู้ใช้ไม่ต้องทำกระบวนการลงชื่อเข้าใช้ข้ามอุปกรณ์ซ้ำอีกในอนาคต หากต้องการตรวจสอบว่าผู้ใช้ลงชื่อเข้าใช้โดยใช้พาสคีย์แบบข้ามอุปกรณ์หรือไม่ ให้ตรวจสอบพร็อพเพอร์ตี้ authenticatorAttachment ของข้อมูลเข้าสู่ระบบ หากค่าเป็น "cross-platform" แสดงว่าเป็นการตรวจสอบสิทธิ์ข้ามอุปกรณ์ หากเป็นเช่นนั้น ให้อธิบายความสะดวกในการสร้างพาสคีย์ใหม่และ แนะนําขั้นตอนการสร้าง

ซิงค์รายละเอียดพาสคีย์กับผู้ให้บริการโดยใช้สัญญาณ

เพื่อรักษาความสอดคล้องและมอบประสบการณ์การใช้งานที่ดียิ่งขึ้นแก่ผู้ใช้ Relying Party (RP) สามารถใช้ WebAuthn Signals API เพื่อสื่อสารการอัปเดตเกี่ยวกับข้อมูลเข้าสู่ระบบและข้อมูลผู้ใช้กับผู้ให้บริการพาสคีย์

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติที่ดีในการรักษาพาสคีย์ให้สอดคล้องกันได้ที่ รักษาพาสคีย์ให้สอดคล้องกับข้อมูลเข้าสู่ระบบในเซิร์ฟเวอร์ด้วย Signal API

ไม่ต้องขอปัจจัยที่ 2

พาสคีย์ให้การป้องกันในตัวที่มีประสิทธิภาพจากภัยคุกคามที่พบบ่อย เช่น ฟิชชิง ดังนั้นปัจจัยการตรวจสอบสิทธิ์ที่ 2 จึงไม่ได้เพิ่มมูลค่าด้านความปลอดภัยอย่างมีนัยสำคัญ แต่กลับสร้างขั้นตอนที่ไม่จำเป็นสำหรับผู้ใช้ในระหว่างการลงชื่อเข้าใช้

เช็กลิสต์

• อนุญาตให้ผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์ผ่านการป้อนข้อความอัตโนมัติในแบบฟอร์ม
• ส่งสัญญาณเมื่อไม่พบข้อมูลเข้าสู่ระบบที่ตรงกับพาสคีย์ในแบ็กเอนด์
• แจ้งให้ผู้ใช้สร้างพาสคีย์ด้วยตนเองหากผู้ใช้ยังไม่ได้สร้างหลังจากลงชื่อเข้าใช้
• สร้างพาสคีย์โดยอัตโนมัติ (สร้างแบบมีเงื่อนไข) หลังจากที่ผู้ใช้ลงชื่อเข้าใช้ด้วยรหัสผ่าน (และปัจจัยที่สอง)
• แจ้งให้สร้างพาสคีย์ในเครื่องหากผู้ใช้ลงชื่อเข้าใช้ด้วยพาสคีย์แบบข้ามอุปกรณ์
• ส่งสัญญาณรายการพาสคีย์ที่พร้อมใช้งานและรายละเอียดผู้ใช้ที่อัปเดตแล้ว (ชื่อผู้ใช้ ชื่อที่แสดง) ไปยังผู้ให้บริการหลังจากลงชื่อเข้าใช้หรือเมื่อมีการเปลี่ยนแปลง

แหล่งข้อมูล

• การตรวจสอบสิทธิ์ด้วยพาสคีย์ฝั่งเซิร์ฟเวอร์
• สร้างพาสคีย์สำหรับการเข้าสู่ระบบแบบไม่มีรหัสผ่าน
• ช่วยผู้ใช้จัดการพาสคีย์อย่างมีประสิทธิภาพ
• พาสคีย์
• เอกสารของ Apple: การตรวจสอบสิทธิ์ผู้ใช้ผ่านเว็บเซอร์วิส
• เอกสารของ Google: การเข้าสู่ระบบแบบไม่มีรหัสผ่านด้วยพาสคีย์