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

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

Eiji Kitamura

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

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

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

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

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

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

UI แบบมีเงื่อนไข

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

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

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

สำเร็จ: เมื่อผู้ใช้ลงชื่อเข้าใช้ด้วยรหัสผ่าน ให้พิจารณาใช้โอกาสนั้นเพื่อเสนอให้สร้างพาสคีย์

วิธีการทำงาน

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

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

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

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

สิ่งที่ต้องดำเนินการก่อน

WebAuthn UI แบบมีเงื่อนไขได้รับการรองรับแบบสาธารณะใน Safari ใน iOS 16, iPadOS 16 และ macOS Ventura นอกจากนี้ยังพร้อมใช้งานบน Chrome ใน Android, macOS และ Windows 11 22H2 ด้วย

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

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

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

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

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

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

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

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

// Availability of `window.PublicKeyCredential` means WebAuthn is usable.  
if (window.PublicKeyCredential &&  
    PublicKeyCredential.​​isConditionalMediationAvailable) {  
  // Check if conditional mediation is available.  
  const isCMA = await PublicKeyCredential.​​isConditionalMediationAvailable();  
  if (isCMA) {  
    // Call WebAuthn authentication  
  }  
}  

เรียกชาเลนจ์จากเซิร์ฟเวอร์ RP

ดึงข้อมูลชาเลนจ์จากเซิร์ฟเวอร์ RP ที่จำเป็นต้องใช้เพื่อเรียกใช้ navigator.credentials.get():

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

• userVerification: ระบุว่าการยืนยันผู้ใช้โดยใช้การล็อกหน้าจอของอุปกรณ์คือ "required", "preferred" หรือ "discouraged" ค่าเริ่มต้นคือ "preferred" ซึ่งหมายความว่า Authenticator อาจข้ามการยืนยันผู้ใช้ โปรดตั้งค่าเป็น "preferred" หรือไม่ใช้พร็อพเพอร์ตี้นี้

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

หมายเหตุ: ค่า ArrayBuffer ที่โอนจากเซิร์ฟเวอร์ เช่น challenge, user.id และข้อมูลเข้าสู่ระบบ id สำหรับ excludeCredentials ต้องเข้ารหัสเมื่อส่งข้อมูล อย่าลืมถอดรหัสในฟรอนท์เอนด์ของ RP ก่อนที่จะส่งค่าไปยังการเรียก WebAuthn API เราขอแนะนำให้ใช้การเข้ารหัส Base64URL

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

เรียกใช้ navigator.credentials.get() เพื่อเริ่มรอการตรวจสอบสิทธิ์ผู้ใช้

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

const publicKeyCredentialRequestOptions = {
  // Server generated challenge
  challenge: ****,
  // The same RP ID as used during registration
  rpId: 'example.com',
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

• rpId: รหัส RP คือโดเมนและเว็บไซต์จะระบุโดเมนหรือคำต่อท้ายที่จดทะเบียนได้ ค่านี้ต้องตรงกับ rp.id ที่ใช้เมื่อสร้างพาสคีย์

อย่าลืมระบุ mediation: 'conditional' เพื่อทำให้คำขอมีเงื่อนไข

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

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

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

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

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

ออบเจ็กต์ข้อมูลเข้าสู่ระบบคีย์สาธารณะจะมีพร็อพเพอร์ตี้ต่อไปนี้

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

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

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

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

ค้นหารหัสข้อมูลเข้าสู่ระบบที่ตรงกันกับพร็อพเพอร์ตี้ id (หากต้องการระบุบัญชีผู้ใช้ ให้ใช้พร็อพเพอร์ตี้ userHandle ซึ่งเป็น user.id ที่คุณระบุเมื่อสร้างข้อมูลเข้าสู่ระบบ) ดูว่า signature ของข้อมูลเข้าสู่ระบบยืนยันด้วยคีย์สาธารณะที่จัดเก็บไว้ได้หรือไม่ ในการทำเช่นนี้ เราขอแนะนำให้ใช้ไลบรารีฝั่งเซิร์ฟเวอร์หรือโซลูชันแทนการเขียนโค้ดเอง คุณสามารถหาไลบรารีโอเพนซอร์สได้ในที่เก็บ GitHub ของ Webauth

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

แหล่งข้อมูล

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