คู่มือนักพัฒนาพาสคีย์สำหรับบุคคลที่พึ่งพา

ดูวิธีผสานรวมพาสคีย์ไว้ในบริการ

โครงสร้างของระบบพาสคีย์

ระบบพาสคีย์ประกอบด้วยองค์ประกอบ 2-3 อย่าง ได้แก่

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

ขั้นตอนการลงทะเบียน

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

หากต้องการสร้างพาสคีย์ใหม่ มีองค์ประกอบหลัก 2-3 อย่างที่ต้องระบุดังนี้

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

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

ขั้นตอนการลงทะเบียน

ดูวิธีสร้างและลงทะเบียนพาสคีย์โดยละเอียดที่

ขั้นตอนการตรวจสอบสิทธิ์

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

หากต้องการตรวจสอบสิทธิ์ด้วยพาสคีย์ มีองค์ประกอบหลัก 2-3 อย่างที่ต้องระบุ ได้แก่

  • รหัส RP: ระบุรหัสของฝ่ายที่เกี่ยวข้องในรูปแบบโดเมนเว็บ
  • การท้า: ชาเลนจ์ที่เซิร์ฟเวอร์สร้างขึ้นซึ่งป้องกันการโจมตีซ้ำ

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

ขั้นตอนการตรวจสอบสิทธิ์

ดูวิธีตรวจสอบสิทธิ์ด้วยพาสคีย์โดยละเอียดที่

การผสานรวมฝั่งเซิร์ฟเวอร์

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

ดูข้อมูลเพิ่มเติมในคำแนะนำฝั่งเซิร์ฟเวอร์ของเรา

กลไกการตรวจสอบสิทธิ์ (เดิม) ที่มีอยู่

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

ซึ่งมีสาเหตุ 2-3 ประการดังนี้

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

ย้อนกลับไปที่กลไกการตรวจสอบสิทธิ์ที่มีอยู่

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

รหัสผ่าน

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

การตรวจสอบสิทธิ์แบบ 2 ปัจจัย

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

หากเลือก SMS เป็นวิธีส่ง OTP โปรดดูแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อปรับปรุงประสบการณ์ของผู้ใช้ในการป้อน OTP

การรวมศูนย์ข้อมูลประจำตัว

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

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

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

แหล่งข้อมูลการเรียนรู้

เว็บไซต์

หากต้องการผสานรวมพาสคีย์ในเว็บไซต์ ให้ใช้ Web Authentication API (WebAuthn) หากต้องการดูข้อมูลเพิ่มเติม โปรดดูแหล่งข้อมูลต่อไปนี้

Android

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

UX

ดูคำแนะนำเกี่ยวกับประสบการณ์ของผู้ใช้พาสคีย์