มอบประสบการณ์การลงชื่อเข้าใช้และข้อมูลเข้าสู่ระบบดิจิทัลที่ราบรื่นบน Android

สวัสดีทุกคน

ขอขอบคุณทุกคนที่เข้ามาฟังกันในวันนี้

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

ผมชื่อ Tom Colvin

ผมเป็น CTO ของ Apptaura และเป็น GDE ด้าน Android และผมมาพร้อมกับ Chiping Yeh ซึ่งเป็นวิศวกรอาวุโสฝ่ายนักพัฒนาแอป Android สัมพันธ์ที่ Google

รหัสผ่านที่ใช้กันมานานกำลังจะหมดไป

หรืออย่างน้อยก็ควรจะเป็นเช่นนั้น

วันนี้เราจะมาพูดถึงโลกที่ไร้รหัสผ่านกัน

รหัสผ่านเป็นช่องโหว่ที่ทราบกันดีในโครงสร้างพื้นฐานด้านความปลอดภัยของเรา

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

ในฐานะอุตสาหกรรม เราได้พยายามแก้ไขปัญหานี้ด้วยการบังคับใช้ความซับซ้อน เช่น อักขระพิเศษ ตัวเลข การหมุนเวียนที่บังคับ

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

เพราะรหัสผ่านที่ซับซ้อนซึ่งมีการเปลี่ยนเป็นประจำมักจะเป็นรหัสผ่านที่ผู้ใช้จดไว้ในกระดาษโน้ต

และแม้แต่การตรวจสอบสิทธิ์แบบ 2 ปัจจัยผ่าน SMS ก็ยังเสี่ยงต่อการถูกดักจับ เช่น การสลับซิม

แต่ในปัจจุบัน ปัญหานี้ได้รับการแก้ไขเป็นส่วนใหญ่แล้ว

พาสคีย์สร้างขึ้นตามมาตรฐาน FIDO และใช้วิทยาการเข้ารหัสคีย์สาธารณะ-ส่วนตัว

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

แถลงการณ์ของเราในวันนี้เป็นเรื่องง่ายๆ

ถึงเวลาเปลี่ยนไปใช้โลกที่ไร้รหัสผ่านแล้ว

และเครื่องมือที่จะทำเช่นนั้นก็อยู่ในมือเราแล้ว

หัวใจสำคัญของการก้าวกระโดดครั้งนี้บน Android คือ Jetpack Credential Manager

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

คุณเรียกใช้ Credential Manager API และ API จะจัดการ UI เพื่อเลือกวิธีการตรวจสอบสิทธิ์ที่ผู้ใช้ต้องการเห็น

จากนั้นระบบจะดำเนินการอย่างหนักเพื่อแสดงข้อมูลเข้าสู่ระบบที่ถูกต้องซึ่งได้รับมาอย่างปลอดภัย

ซึ่งรองรับการลงชื่อเข้าใช้ การลงชื่อสมัครใช้ และการสำรองข้อมูลเข้าสู่ระบบ

และคุณสามารถใช้เพื่ออัปเดตและลบข้อมูลเข้าสู่ระบบได้

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

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

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

และที่สำคัญที่สุดสำหรับเราคือมีขั้นตอนเฉพาะสำหรับพาสคีย์

นี่คือสิ่งที่ผู้ใช้จะเห็นในระหว่างการลงชื่อสมัครใช้

แอปของฉันจะแจ้ง Credential Manager ว่าการตรวจสอบสิทธิ์ด้วยพาสคีย์พร้อมใช้งาน และจะให้รายละเอียดที่รวบรวมจากแบ็กเอนด์

คุณแตะ "ลงทะเบียน" แล้ว Credential Manager จะแสดง Bottom Sheet พร้อมข้อความแจ้งให้ล็อกหน้าจอ

โดยส่วนใหญ่แล้วจะปลดล็อกด้วยข้อมูลไบโอเมตริก เช่น ลายนิ้วมือหรือการสแกนใบหน้า

จากนั้น Credential Manager จะจัดการงานวิทยาการเข้ารหัสที่ซับซ้อน เช่น การสร้างพาสคีย์จริงๆ

และระบบจะบันทึกพาสคีย์ลงใน Credential Manager ซึ่งในกรณีนี้คือเครื่องมือจัดการรหัสผ่านบน Google แต่อาจเป็นเครื่องมืออื่นก็ได้

โค้ดจะมีลักษณะดังนี้

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

ก่อนอื่น เราจะสร้างออบเจ็กต์ createPublicKeyCredentialRequest นี้โดยใช้รายละเอียดที่แบ็กเอนด์ระบุ ซึ่งก็คือ registerRequestJson นี้

จากนั้นเราจะเรียกใช้เมธอดวิเศษ credentialManager.createCredential

เราจะส่งคำขอนั้นและบริบทเฉพาะรายการ ซึ่งจะช่วยให้แสดง UI ได้

โปรดทราบว่าผมไม่จำเป็นต้องเขียนโค้ด UI ใดๆ เลยที่นี่

Credential Manager จะจัดการเรื่องนี้ให้เราทั้งหมด

ขั้นตอนการลงชื่อเข้าใช้มีดังนี้

สำหรับผู้ใช้ ขั้นตอนนี้จะดูคล้ายกับขั้นตอนการลงชื่อสมัครใช้เป็นอย่างมาก

คุณจะเห็นข้อความแจ้งให้ปลดล็อกเพียงครั้งเดียวก็เสร็จเรียบร้อย

สำหรับนักพัฒนาแอป ขั้นตอนจะแตกต่างกันเล็กน้อย

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

ก่อนอื่น เราจะรับรายละเอียดการลงชื่อเข้าใช้จากแบ็กเอนด์เพื่อสร้างอินสแตนซ์ GetPublicKeyCredential

เราจะบอก Credential Manager ว่าเรารองรับข้อมูลเข้าสู่ระบบประเภทใดบ้าง

ในที่นี้จะใช้เฉพาะพาสคีย์เท่านั้น

แต่เราก็เพิ่มข้อมูลเข้าสู่ระบบประเภทอื่นๆ ได้ด้วยหากต้องการ

จากนั้นเราจะเรียกใช้ credentialManager.getCredential โดยส่งรายการข้อมูลเข้าสู่ระบบที่เราเพิ่งขอไป

ขอย้ำอีกครั้งว่าไม่มีโค้ด UI

โดยไม่จำเป็นต้องเขียนโค้ด UI ใดๆ

Credential Manager จะจัดการเรื่องนี้ให้เราอย่างสมบูรณ์

โดยจะกระตุ้นให้ผู้ใช้เลือกตัวเลือกที่ใช้บ่อยที่สุด และเก็บตัวเลือกอื่นๆ ไว้เป็นตัวเลือกสำรอง

ซึ่งจะช่วยแก้ปัญหาการตรวจสอบสิทธิ์ที่น่ารำคาญที่สุดปัญหาหนึ่งในปัจจุบันได้โดยอัตโนมัติ

คุณสังเกตเห็นไหม

ซึ่งก็คือการจดจำวิธีการที่ฉันใช้ลงชื่อเข้าใช้ครั้งล่าสุด

ดูสิ คำตอบแสดงไว้อย่างเป็นระเบียบใน Bottom Sheet

ซึ่งนอกจากจะสร้างความรำคาญให้ผู้ใช้แล้ว

ซึ่งเป็นจุดที่ทำให้เกิดความขัดแย้งอย่างแท้จริง

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

นี่คือโค้ดของแอปพลิเคชันสาธิตที่คุณสามารถใช้เพื่อลองใช้ Credential Manager ด้วยตนเอง

และคุณจะเห็นขั้นตอนเหล่านี้ในอุปกรณ์ของคุณเอง

และมีตัวอย่างโค้ดอย่างเป็นทางการของ Goo-- อยู่ทางด้านซ้าย

ซึ่งจะจัดการการสร้างพาสคีย์

แล้วการอัปเกรดผู้ใช้รหัสผ่านที่มีอยู่เป็นพาสคีย์ล่ะ

เครื่องมือที่มีประสิทธิภาพสำหรับเรื่องนี้คือการสร้างแบบมีเงื่อนไข

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

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

ซึ่งจะไม่รบกวนเวิร์กโฟลว์ของผู้ใช้

รหัสผ-- พาสคีย์จะสร้างขึ้นโดยอัตโนมัติและจัดเก็บไว้

เครื่องมือจัดการรหัสผ่านบน Google จะแสดงการแจ้งเตือนเพื่อยืนยันว่ามีการดำเนินการดังกล่าวแล้ว

เครื่องมือจัดการรหัสผ่านอื่นๆ อาจทำงานแตกต่างออกไป

โค้ดสำหรับการสร้างแบบมีเงื่อนไขจะคล้ายกับโค้ดสำหรับการลงชื่อสมัครใช้เป็นอย่างมาก

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

แฟล็กวิเศษเป็น isConditional จริง ซึ่งช่วยให้มั่นใจว่าผู้ใช้จะไม่เห็น UI นั้น

และเนื่องจากฟังก์ชันนี้ทำงานตามโอกาส เราจึงจะใส่ไว้ใน try-catch

เราจะจัดการข้อผิดพลาดอย่างเงียบๆ เพื่อไม่ให้รบกวนผู้ใช้หากกระบวนการล้มเหลว

จากนั้นระบบจะบันทึกพาสคีย์ลงใน Credential Manager ของผู้ใช้ และจะพร้อมใช้งานในครั้งถัดไป

นอกจากนี้ Credential Manager ยังช่วยให้ผู้ให้บริการข้อมูลเข้าสู่ระบบนำเข้าและส่งออกข้อมูลเข้าสู่ระบบได้อย่างปลอดภัย

เพียงไม่กี่คลิก

โดยไม่ต้องดาวน์โหลด

ซึ่งจะช่วยเพิ่มความยืดหยุ่นในการใช้งาน โดยที่ยังคงรักษาข้อมูลให้ปลอดภัย

ขั้นตอนจะมีลักษณะดังนี้

ในผู้ให้บริการข้อมูลเข้าสู่ระบบรายใหม่ ผู้ใช้จะขอให้นำเข้าข้อมูลเข้าสู่ระบบ

จากนั้น Credential Manager จะจัดการ UI การนําเข้า ซึ่งช่วยให้ผู้ใช้เลือกแหล่งที่มาของข้อมูลเข้าสู่ระบบได้

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

และสุดท้าย ผู้ให้บริการข้อมูลเข้าสู่ระบบรายใหม่ของผู้ใช้จะได้รับข้อมูลผ่านช่องทางที่ปลอดภัย

จึงสามารถนำเข้าได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้

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

จากนั้นผู้ให้บริการข้อมูลเข้าสู่ระบบอาจไม่ทราบว่าเกิดเหตุการณ์ดังกล่าวขึ้น

ครั้งถัดไปที่ผู้ใช้พยายามลงชื่อเข้าใช้ Credential Manager จะเสนอพาสคีย์ที่ใช้ไม่ได้นั้น และผู้ใช้จะถูกปฏิเสธการลงชื่อเข้าใช้

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

ตอนนี้แอปของคุณสามารถแจ้งสถานะที่เฉพาะเจาะจงเหล่านี้แก่ผู้ให้บริการข้อมูลเข้าสู่ระบบได้ด้วย Signal API

ลองดูตัวอย่างกรณีการลงชื่อเข้าใช้ด้วยรหัสผ่านที่ถูกเพิกถอน

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

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

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

แต่โปรดทราบว่าเป้าหมายสูงสุดของเราคือการเลิกใช้รหัสผ่านโดยสมบูรณ์

Credential Manager ช่วยให้บรรลุเป้าหมายดังกล่าวได้อย่างไร

กระบวนการ 5 ขั้นตอนที่เราเสนอมีดังนี้

ใน 2 ขั้นตอนแรก คุณจะอัปเกรดผู้ใช้รหัสผ่านเป็นพาสคีย์

ขั้นแรก เราจะพยายามสร้างแบบมีเงื่อนไขตามโอกาส

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

เราจะค่อยๆ เริ่มแสดงข้อมูลเหล่านั้นให้โดดเด่นมากขึ้นเรื่อยๆ

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

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

แต่ผู้ใช้เก่าเหล่านั้นคือผู้ที่เราจะจัดการใน 3 ขั้นตอนสุดท้ายนี้

เราขอแนะนำให้ผู้ใช้พาสคีย์นำรหัสผ่านออก

ดังนั้นในขั้นตอนที่ 3 เราจึงอนุญาตให้ผู้ใช้ดำเนินการนี้ด้วยตนเอง โดยมีตัวเลือก "ลบรหัสผ่าน" ที่ชัดเจนมากในการตั้งค่าบัญชี

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

และสุดท้าย คุณเปลี่ยนจากการลบรหัสผ่านแบบเลือกใช้เป็นแบบเลือกไม่ใช้

ในที่สุดแล้ว แม้แต่การเลือกไม่ใช้ครั้งสุดท้ายก็อาจหายไป

ข้อมูลวิเคราะห์จะช่วยให้เรามั่นใจที่จะนำขั้นตอนการป้อนรหัสผ่านออกจากแอปโดยสิ้นเชิง

ดังนั้น การเปลี่ยนไปใช้โลกที่ไร้รหัสผ่านจึงไม่ใช่แนวคิดด้านความปลอดภัยเชิงทฤษฎีสำหรับอนาคตอีกต่อไป

ซึ่งเป็นสิ่งที่ได้รับการสนับสนุนอย่างมาก

API มีประสิทธิภาพและประสบการณ์ของผู้ใช้ก็ยอดเยี่ยม

เราขอแนะนำให้คุณเริ่มผสานรวมขั้นตอนการใช้พาสคีย์กับ Credential Manager เลยวันนี้

เริ่มอัปเกรดผู้ใช้ของคุณ และบอกลารหัสผ่านไปได้เลย

ขอขอบคุณ

ตอนนี้ฉันขอส่งต่อให้ Chiping พูดถึงวิวัฒนาการขั้นต่อไปในการย้ายข้อมูลอุปกรณ์และข้อมูลประจำตัว

เยี่ยมเลย

โอเค ขอบคุณนะ Tom

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

แต่จะเกิดอะไรขึ้นเมื่อผู้ใช้เปลี่ยนโทรศัพท์ใหม่

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

วันนี้เราจะมาพูดถึงวิธีแก้ปัญหาดังกล่าวและอธิบายสั้นๆ เกี่ยวกับข้อกำหนดของ Play Store ที่กำลังจะมีขึ้นเกี่ยวกับการกู้คืนข้อมูลเข้าสู่ระบบ

ตั้งแต่เดือนเมษายน 2027 เป็นต้นไป Google Play จะกำหนดให้แอปต้องเป็นไปตามข้อกำหนดการลงชื่อเข้าใช้แบบไม่ต้องแตะเพื่อรักษาความสามารถในการเผยแพร่แอปอย่างเต็มรูปแบบและการแสดงผลที่เหมาะสมที่สุดใน Play Store

การลงชื่อเข้าใช้แบบไม่ต้องแตะคืออะไร

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

เราจะติดตั้งใช้งานได้อย่างไร

วิธีหลักที่เราแนะนำในการดำเนินการนี้คือผ่าน Restore Credentials API ของ Android ผ่าน Credential Manager

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

เราขอแนะนำให้สร้างคีย์นี้ในเบื้องหลังเมื่อผู้ใช้ลงชื่อเข้าใช้แล้ว

แผนภาพนี้แสดงให้เห็นผู้ใช้ที่ลงชื่อเข้าใช้แอป

จากนั้นระบบจะสร้างคีย์การกู้คืนขณะที่ผู้ใช้ใช้แอป ณ จุดใดจุดหนึ่ง

จากนั้นระบบจะจัดเก็บคีย์นี้ไว้ในเครื่อง หรือจัดเก็บไว้ในระบบคลาวด์จากระยะไกลหากเปิดใช้

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

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

จากนั้นเมื่อเปิดแอป คุณจะเรียกใช้ Credential Manager API เพื่อใช้คีย์การกู้คืนนี้เพื่อลงชื่อเข้าใช้ผู้ใช้ในอุปกรณ์เครื่องใหม่เมื่อเปิดแอปครั้งแรกได้

ซึ่งจะช่วยให้ผู้ใช้เข้าสู่ระบบแอปของคุณได้อย่างรวดเร็วและปลอดภัยทันที

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

ซึ่งจะช่วยให้ผู้ใช้เข้าสู่ระบบแอปได้โดยไม่ต้องเปิดแอปด้วยตนเอง

พาร์ทเนอร์บางรายของเราได้นำฟีเจอร์นี้ไปใช้ในแอปแล้ว

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

ความง่ายในการเข้าถึงเป็นสิ่งสำคัญ

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

การเปลี่ยนอุปกรณ์บ่อยครั้งนี้ทำให้การคงผู้ใช้ไว้เป็นเรื่องที่ท้าทาย

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

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

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

ขอย้ำอีกครั้งว่าการเปลี่ยนแปลงนี้จะเกิดขึ้นในเดือนเมษายน 2027 ดังนั้นโปรดอย่าลืมทำเครื่องหมายในปฏิทิน

และหากต้องการเริ่มต้นใช้งาน Restore Credentials ในแอปก่อนใคร โปรดดูคิวอาร์โค้ดและลิงก์นี้เพื่อเข้าถึงทักษะ Restore Credentials ของเรา

ทักษะนี้สามารถใช้เพื่อช่วยพัฒนาหรือทดสอบฟีเจอร์กับ Agent ที่คุณเลือกได้อย่างรวดเร็ว

ตอนนี้เรามาดูอนาคตของข้อมูลประจำตัวดิจิทัลกัน นั่นคือ Digital Credentials API ผ่าน Credential Manager

มาดูข้อมูลเกี่ยวกับข้อมูลเข้าสู่ระบบดิจิทัลและวิธีการทำงานกัน

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

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

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

เอกสารรับรองดิจิทัลเป็นวิธีที่ปลอดภัยและสะดวกในการแชร์ข้อมูลโดยไม่ต้องใช้บัตรจริง (Physical Card)

ข้อมูลเข้าสู่ระบบดิจิทัลเกี่ยวข้องกับ 3 ฝ่าย ได้แก่ ผู้ออก ผู้ถือ และผู้ตรวจสอบ

โดยทั่วไปแล้ว วงจรชีวิตของข้อมูลเข้าสู่ระบบดิจิทัลจะดำเนินจากซ้ายไปขวา

มาดูเอนทิตีแต่ละรายการและบทบาทของเอนทิตีกัน

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

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

และจริงๆ แล้วใครๆ ก็เป็นผู้ออกบัตรได้ ไม่ว่าจะเป็นยิม โรงแรม หรือแม้แต่ตัวคุณเอง

คุณเพียงแค่ต้องสร้างข้อมูลเข้าสู่ระบบและลงชื่อเข้าใช้

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

ซึ่งก็คือฝ่ายถัดไปที่เรียกว่าผู้ถือ ซึ่งมักจะเรียกว่ากระเป๋าเงินดิจิทัลด้วย

ผู้ถือครองตามชื่อที่ระบุจะถือข้อมูลเข้าสู่ระบบที่ออกโดยผู้ออกเป็นหลัก

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

และทุกคนสามารถเป็นผู้ถือได้เช่นเดียวกับผู้ออกบัตร

อันที่จริงแล้ว ไม่ใช่เรื่องแปลกที่ผู้ออกและผู้ถือจะได้รับการจัดการโดยนิติบุคคลเดียวกัน

ลองนึกถึงฟิตเนสที่ต้องการสร้างข้อมูลเข้าสู่ระบบการเป็นสมาชิกแบบดิจิทัลของตนเองและจัดการข้อมูลดังกล่าวผ่านแอปของตนเอง

ซึ่งจะเป็นทั้งผู้ออกบัตรและผู้ถือบัตรในหนึ่งเดียว

โอเค บุคคลที่สามคือผู้ตรวจสอบ หรือฝ่ายที่ขอเอกสารรับรองดิจิทัล

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

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

ใน Android การโต้ตอบระหว่างทั้ง 3 ฝ่ายนี้กับผู้ใช้จะได้รับการประสานงานผ่าน Credential Manager ด้วย Digital Credentials API

ผู้ออกสามารถเรียกใช้ API เพื่อออกข้อมูลเข้าสู่ระบบให้แก่ผู้ถือได้ แม้ว่าจะไม่จำเป็นหากเป็นบุคคลเดียวกัน

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

Credential Manager จะจับคู่คำขอกับผู้ถือทั้งหมดที่มีอยู่ และแสดงให้ผู้ใช้เห็นเพื่อเลือกข้อมูลเข้าสู่ระบบและให้ความยินยอม

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

เมื่อผู้ตรวจสอบได้รับข้อมูลเข้าสู่ระบบแล้ว ก็สามารถตรวจสอบความถูกต้องของข้อมูลเข้าสู่ระบบได้หลายวิธี รวมถึงการตรวจสอบผู้ออกข้อมูลเข้าสู่ระบบเดิม

ตอนนี้คุณอาจสงสัยว่าเอกสารรับรองดิจิทัลปลอดภัยอย่างไร

จริงๆ แล้วมีการรักษาความปลอดภัยในแต่ละขั้นตอนของกระบวนการ และเราจะพูดถึงบางส่วนในตอนนี้

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

ระบบจะยืนยันได้อย่างไร

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

ผู้ถือจะส่งเอกสารรับรองกระเป๋าเงิน ซึ่งโดยปกติจะอยู่ในรูปแบบเชนใบรับรองที่ยืนยันได้

ผู้ถือยังสร้างคู่คีย์ที่เชื่อมโยงกับฮาร์ดแวร์ด้วย

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

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

ในฝั่งผู้ถือ เมื่อผู้ถือมีข้อมูลเข้าสู่ระบบใหม่ ระบบจะลงทะเบียนเฉพาะข้อมูลเมตาของข้อมูลเข้าสู่ระบบกับ Credential Manager

Credential Manager จะใช้ข้อมูลเมตานี้เพื่อพิจารณาว่าจะแสดงผู้ถือรายใดเมื่อผู้ตรวจสอบส่งคำขอข้อมูลเข้าสู่ระบบ

ระบบจะไม่ลงทะเบียนข้อมูลผู้ใช้จริงกับ Credential Manager หรือเปิดเผยข้อมูลดังกล่าวต่อ Google

และแม้ว่า Credential Manager จะเลือกกระเป๋าเงินเพื่อแสดงต่อผู้ใช้ แต่เนื้อหาภายในกระเป๋าเงินแต่ละใบจะไม่แสดง ณ จุดนั้น

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

คุณอาจจำได้ว่าตัวยึดเป็นเพียงแอป ดังนั้นแอปจึงถูกเรียกใช้

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

Google ไม่สามารถเข้าถึงข้อมูลเข้าสู่ระบบได้

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

ซึ่งช่วยให้ผู้ถือสามารถควบคุมได้ว่าจะแชร์เอกสารรับรองกับบุคคลใดบ้าง

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

ตอนนี้ผู้ตรวจสอบจะตรวจสอบได้ว่าการตอบกลับสร้างขึ้นใหม่โดยผู้ถือข้อมูลเข้าสู่ระบบเดิมสำหรับคำขอหรือไม่

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

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

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

เมื่อเราได้พูดถึงความปลอดภัยของเอกสารรับรองดิจิทัลแล้ว มาดู Use Case บางส่วนของเอกสารรับรองดิจิทัลที่พร้อมใช้งานในปัจจุบันผ่าน Digital Credentials API บน Android กัน

วิธีแรกที่เราจะพูดถึงเรียกว่าการยืนยันอีเมล

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

ซึ่งหมายความว่าผู้ใช้จะไม่ต้องออกจากแอปและเพียงแค่ให้ความยินยอมด้วยการแตะเพียงครั้งเดียวที่ Bottom Sheet ของ Credential Manager ที่คุ้นเคย

ต่อไปนี้คือการสาธิตการบันทึกการสาธิตการทำงานของ API

นี่คือแอปตัวอย่างที่ใช้การยืนยันอีเมลผ่าน Digital Credentials API

เมื่อฉันแตะ "ขออีเมลที่ยืนยันแล้ว" Credential Manager จะขอข้อมูลเข้าสู่ระบบดิจิทัลของอีเมลที่ยืนยันแล้วจากผู้ถือในอุปกรณ์ที่มีข้อมูลเข้าสู่ระบบประเภทนี้

ในกรณีนี้ Google เป็นผู้ถือข้อมูลเข้าสู่ระบบของอีเมลที่ยืนยันแล้วนี้เพียงผู้เดียว ซึ่งคุณจะเห็นข้อมูลดังกล่าวแสดงใน Bottom Sheet

นี่เป็นหนึ่งในอีเมลที่ผู้ใช้เข้าสู่ระบบในอุปกรณ์

และในกรณีนี้ Google เป็นทั้งผู้ออกและผู้ถือข้อมูลเข้าสู่ระบบดิจิทัล

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

ในแอป คุณสามารถใช้ข้อมูลนี้เพื่อไปยังหน้าจอถัดไปของแอป เช่น การสร้างพาสคีย์หรือขั้นตอนการสร้างบัญชีอื่นๆ

สำหรับผู้ใช้ การดำเนินการนี้ง่ายพอๆ กับการให้ความยินยอมแล้วไปยังหน้าจอถัดไป

หากต้องการลองใช้ คุณสามารถไปที่ตัวอย่าง GitHub และติดตั้งในอุปกรณ์ของคุณเอง

โปรดลองใช้ในอุปกรณ์จริง และโปรดทราบว่าคุณจะต้องลงชื่อเข้าใช้บัญชี Gmail อย่างน้อย 1 บัญชีในอุปกรณ์

ดังนั้น เราจะให้เวลาเพิ่มอีกเล็กน้อยหากผู้คนสนใจ

โอเค

ฟังดูน่าตื่นเต้นใช่ไหม

และเมื่อนึกถึงการยืนยันอีเมล คุณนึกถึงการยืนยันผู้ใช้รูปแบบใดเป็นอันดับถัดไป

ถูกต้อง การยืนยันหมายเลขโทรศัพท์

นอกจากนี้ Digital Credentials API ยังรองรับการยืนยันหมายเลขโทรศัพท์โดยค่าเริ่มต้น ซึ่งช่วยลดความยุ่งยากและช่องโหว่ของ OTP ทาง SMS

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

ผู้ใช้จะเห็นเฉพาะ Bottom Sheet ของ Credential Manager ที่คุ้นเคยเพื่อแชร์หรือยืนยันหมายเลขโทรศัพท์ โดยจะยังคงอยู่ในแอป และต้องแตะเพียงไม่กี่ครั้งเพื่อทำการยืนยันให้เสร็จสมบูรณ์

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

แล้วการตั้งค่านี้ทำงานอย่างไร

หากเราจับคู่สิ่งนี้กับฝ่ายที่เกี่ยวข้องกับเอกสารรับรองดิจิทัล ผู้ออกเอกสารในกรณีนี้คือผู้ให้บริการโทรศัพท์ของหมายเลขโทรศัพท์ในซิมการ์ดของอุปกรณ์ และผู้ถือเอกสารคือ Android Telephony

เมื่อผู้ตรวจสอบ เช่น แอปของคุณ ขอหมายเลขโทรศัพท์ของผู้ใช้ ระบบจะดึงหมายเลขโทรศัพท์ดังกล่าวจาก Google Telephony ด้วยการเรียก Digital Credentials API

คุณอาจสงสัยว่าการเรียกเก็บเงินทำงานอย่างไร

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

ซึ่งจะเกิดขึ้นหลังจากดึงข้อมูลหมายเลขโทรศัพท์จาก Google Telephony ซึ่งจัดเก็บไว้ในสถานะที่เข้ารหัส

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

ข้อดีคือผู้ให้บริการจะเรียกเก็บเงินเฉพาะการยืนยันที่สำเร็จ ซึ่งจะโอนผ่านอินเทอร์เน็ตหรือ Wi-Fi และเชื่อถือได้มากกว่า SMS มาก

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

แอปขอหมายเลขโทรศัพท์ของผู้ใช้เป็นส่วนหนึ่งของกระบวนการลงชื่อเข้าใช้

ผู้ใช้รายนี้มีซิมการ์ดหลายอัน และเลือกซิมการ์ด 1 อันเพื่อแชร์กับแอป

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

จากนั้น คุณจะเห็นหน้าจอถัดไปพร้อมหมายเลขโทรศัพท์ที่ดึงมา

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

เพียงปล่อยให้ขั้นตอนนี้เสร็จสิ้น คุณก็จะเห็นการดำเนินการเสร็จสมบูรณ์อีกครั้ง

คุณจึงเห็นหมายเลขโทรศัพท์ในหน้าจอสุดท้ายนั้น

ง่ายๆ แค่นี้เอง

วันนี้เราได้พูดถึงเนื้อหาไปมากมาย

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

โปรดดูแหล่งข้อมูลเกี่ยวกับ Credential Manager และพาสคีย์ที่นี่เพื่อดูข้อมูลเพิ่มเติมและเข้าถึงแอปตัวอย่างของเรา

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

Play Store จะบังคับใช้ข้อกำหนดนี้ภายในเดือนเมษายน 2027 ดังนั้นโปรดจดบันทึกไว้ในปฏิทิน

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

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

ทุกอย่างที่เราแชร์ในวันนี้พร้อมให้คุณนำไปใช้สร้างสรรค์แล้ว

อนาคตของข้อมูลประจำตัวใน Android มาถึงแล้ว และน่าตื่นเต้นกว่าที่เคย

ขอขอบคุณที่สละเวลา และเราทราบว่าตอนนี้เป็นเวลาอาหารกลางวัน ดังนั้นโปรดเพลิดเพลินกับอาหารด้านนอก

และหากมีคำถามเกี่ยวกับพาสคีย์หรือข้อมูลเข้าสู่ระบบดิจิทัล ก็เข้ามาถามฉันหรือ Tom ได้เลย

ขอขอบคุณ