วิธีที่ WhatsApp อัปเกรดเป็นการลงชื่อเข้าใช้ที่ปลอดภัยและราบรื่นสำหรับผู้ใช้ 1 พันล้านคนด้วยพาสคีย์

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

"สิ่งที่ทำให้ฉันตื่นเต้นที่สุดคือผลกระทบที่ยิ่งใหญ่ของ WhatsApp แม้แต่การปรับปรุงเล็กๆ น้อยๆ ใน WhatsApp ก็ส่งผลต่อผู้ใช้หลายพันล้านคนทั่วโลก" Mayank Manuja วิศวกร Android ในทีมการลงทะเบียนและการเข้าถึงของ WhatsApp ซึ่งเป็นผู้นำในการออกแบบและการใช้งานการตรวจสอบสิทธิ์โดยใช้พาสคีย์สำหรับ WhatsApp กล่าว 

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

การตัดสินใจใช้พาสคีย์

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

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

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

การผสานรวมฝั่งไคลเอ็นต์

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

แม้ว่าเส้นทางที่ไม่พบข้อผิดพลาดจะทำงานได้ตั้งแต่เริ่มต้น แต่การไปยังส่วนต่างๆ ของฐานผู้ใช้ที่หลากหลายใน OEM, Android เวอร์ชันต่างๆ และการกำหนดค่าอุปกรณ์ที่หลากหลาย (เช่น PIN เท่านั้นเทียบกับข้อมูลไบโอเมตริก หรือ Android 13 เทียบกับ 14 ขึ้นไป) ทำให้เกิดกรณีที่พบไม่บ่อยนักซึ่งไม่เคยเกิดขึ้นมาก่อน ซึ่งรวมถึงผู้ใช้ที่ไม่มีการล็อกหน้าจอ, ประเภทข้อยกเว้นที่ไม่คาดคิด, บริการ Google Play ที่ล้าสมัย และลักษณะการทำงานของผู้ให้บริการข้อมูลเข้าสู่ระบบที่ไม่สอดคล้องกัน

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

• การเพิ่มประสิทธิภาพขั้นตอนการค้นหาข้อมูลเข้าสู่ระบบ: ขั้นตอนการค้นหาข้อมูลเข้าสู่ระบบในตอนแรกมีเวลาในการตอบสนองต่ำ โดยเฉพาะสำหรับผู้ใช้ที่ยังไม่ได้สร้างพาสคีย์ เนื่องจากผู้ใช้ WhatsApp ส่วนใหญ่อยู่ในกลุ่มนี้ในช่วงแรกๆ การดำเนินการนี้จึงทำให้การลงชื่อเข้าใช้เกือบทุกครั้งล่าช้าอย่างเห็นได้ชัด การใช้เครื่องมือวัดเส้นทางการโทรและระบุจุดคอขวดร่วมกันช่วยให้ WhatsApp เร่งกระบวนการได้อย่างมาก ซึ่งช่วยเพิ่มประสิทธิภาพที่ส่งผลดีต่อระบบนิเวศของ Android ทั้งหมดในท้ายที่สุด
• การจัดการสถานะชั่วคราว: WhatsApp ได้สร้างเลเยอร์การจัดการข้อผิดพลาดที่ครอบคลุมเพื่อจัดการกับอุปสรรคเฉพาะอุปกรณ์ เช่น ความพร้อมใช้งานของเครื่องมือจัดการรหัสผ่าน การล็อกหน้าจอที่ไม่ได้กำหนดค่า ปัญหาการเชื่อมต่อเป็นระยะๆ ฮาร์ดแวร์ที่เข้ากันไม่ได้ บริการ Google Play ที่ล้าสมัย โดยจัดหมวดหมู่ข้อยกเว้นเป็นสถานะที่กู้คืนได้และสถานะเทอร์มินัล ซึ่งช่วยให้เกิดการลดลงอย่างค่อยเป็นค่อยไป หากขั้นตอนการใช้พาสคีย์ไม่เสร็จสมบูรณ์ ระบบจะเปลี่ยนกลับไปใช้การตรวจสอบสิทธิ์แบบเดิมอย่างปลอดภัยโดยไม่ทำให้ผู้ใช้ติดค้างอยู่ในสถานะที่ใช้งานไม่ได้
• การจัดการข้อยกเว้นเฉพาะระบบปฏิบัติการ: เมื่อการตรวจวัดระยะไกลเผยให้เห็นอุปสรรคเฉพาะอุปกรณ์ เช่น GetPublicKeyCredentialDomException (ถอดรหัสข้อมูลเข้าสู่ระบบไม่สำเร็จ) ในอุปกรณ์ Android 13 บางรุ่น และ CreatePublicKeyCredentialDomException (รับบัญชีที่ซิงค์ไม่ได้) ระหว่างการสร้างพาสคีย์ใน Android 14 ทาง Google และทีม WhatsApp ได้ตรวจสอบสาเหตุของปัญหาและทำการปรับปรุงระดับแพลตฟอร์มเพื่อให้ขั้นตอนการสร้างราบรื่นยิ่งขึ้น คุณสามารถดูคู่มือข้อผิดพลาดที่ครอบคลุมได้ที่นี่ ซึ่งแสดงรหัสข้อผิดพลาดและคำอธิบายที่พบบ่อยเกี่ยวกับ Credential Manager รวมถึงให้ข้อมูลบางอย่างเกี่ยวกับสาเหตุของข้อผิดพลาด 

การปรับปรุงประสบการณ์ของผู้ใช้

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

สถาปัตยกรรมฝั่งเซิร์ฟเวอร์และอุปสรรคข้ามแพลตฟอร์ม

ในแบ็กเอนด์ เซิร์ฟเวอร์ของ WhatsApp จะใช้กระบวนการ WebAuthn/FIDO2 มาตรฐาน แบ็กเอนด์เขียนด้วย Erlang และเรียกใช้ไลบรารี Rust webauthn-rs ผ่านอินเทอร์เฟซแบบเนทีฟ ไลบรารี Rust นี้จะจัดการการยืนยันลายเซ็นและการแยกวิเคราะห์ข้อมูลเข้าสู่ระบบ ซึ่งช่วยให้โค้ดภายในยังคงมุ่งเน้นไปที่การจัดระเบียบ พื้นที่เก็บข้อมูล และกฎของผลิตภัณฑ์ เช่น การมีสิทธิ์ การจำกัดอัตราคำขอ และวงจรของข้อมูลเข้าสู่ระบบ

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

1. การลงทะเบียนพาสคีย์

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

Erlang: เริ่มการลงทะเบียน

begin_registration(UserId) ->
    Existing = list_credentials(UserId),
    %% reuse the existing user handle, or mint a new one
    {UserHandle, IsNew} = user_handle(Existing),
    %% returns the client creation options and the server-side challenge state
    #{client_safe := CreationOptions, server_only := ChallengeState} =
        webauthn:start_registration(UserId, UserHandle, rp_config()),
    %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one
    Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)),
    store_challenge(UserId, ChallengeState),          %% short TTL
    IsNew andalso reserve_user_handle(UserId, UserHandle),
    Options.

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

Erlang: ลงทะเบียนให้เสร็จสิ้น

finish_registration(UserId, Attestation) ->
    ChallengeState = get_challenge(UserId),          %% must exist and be unexpired
    #{credential_id := CredId, public_key := PubKey} =
        webauthn:finish_registration(Attestation, ChallengeState, rp_config()),
    ok = index_credential(CredId, UserId),            %% map credential_id -> account
    case multi_passkey_enabled(UserId) of
        true  -> add_credential(UserId, CredId, PubKey);      %% append (oldest evicted past the cap)
        false -> replace_credential(UserId, CredId, PubKey)   %% single-passkey mode
    end,
    notify_client(UserId, {passkey_created, CredId}),
    ok.

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

2. การตรวจสอบสิทธิ์ข้อมูลเข้าสู่ระบบ

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

Erlang: เริ่มการตรวจสอบสิทธิ์

begin_authentication(UserId) ->
    Credentials = list_valid_credentials(UserId),
    #{client_safe := RequestOptions, server_only := ChallengeState} =
        webauthn:start_authentication(Credentials, rp_config()),
    store_challenge(UserId, ChallengeState),          %% short TTL
    RequestOptions.

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

Erlang: ตรวจสอบสิทธิ์ให้เสร็จสิ้น

finish_authentication(UserId, Assertion) ->
    ChallengeState = get_challenge(UserId),
    Credentials = list_valid_credentials(UserId),
    case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of
        #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result ->
            %% webauthn tells us when the stored credential should be refreshed
            NeedsUpdate andalso refresh_credential(UserId, CredId, Result),
            mark_credential_used(UserId, CredId),
            {ok, CredId};
        _ ->
            {error, not_allowed}
    end.

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการลงทะเบียนเซิร์ฟเวอร์ได้โดยทำตามคู่มือการผสานรวมที่นี่ 

ข้อควรพิจารณาด้านสถาปัตยกรรมขั้นสูง 

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

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

การคิดใหม่เกี่ยวกับการซิงค์ข้อมูลข้ามอุปกรณ์

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

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

ในอนาคต

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

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

คำแนะนำสำหรับนักพัฒนาแอปที่สร้างแอปจำนวนมาก

สำหรับนักพัฒนาแอปที่เตรียมผสานรวมพาสคีย์ในวงกว้าง ทีม WhatsApp มีคำแนะนำที่สำคัญดังนี้

• ลงทุนในการจัดหมวดหมู่ข้อผิดพลาดตั้งแต่เนิ่นๆ: จัดหมวดหมู่ข้อยกเว้นต่างๆ ของ Credential Manager เป็นสถานะที่กู้คืนได้และสถานะที่สิ้นสุด และกำหนดเส้นทางสำรองที่ชัดเจนและราบรื่นสำหรับแต่ละสถานการณ์
• ทำความเข้าใจ Funnel การมีสิทธิ์: ตรวจสอบความสามารถของอุปกรณ์ เช่น การมีอยู่ของการล็อกหน้าจอ ฮาร์ดแวร์ไบโอเมตริก และเวอร์ชันของบริการ Google Play รวมถึงออกแบบขั้นตอนเพื่อยกเว้นผู้ใช้ที่ไม่มีสิทธิ์ในเชิงรุกแทนที่จะดำเนินการไม่สำเร็จระหว่างขั้นตอน
• เตรียมแอปให้พร้อมสำหรับวิธีการสำรอง: ใช้พาสคีย์เป็นวิธีการตรวจสอบสิทธิ์หลักที่เหมาะสมที่สุดสำหรับอุปกรณ์ที่รองรับ แต่ให้คงวิธีการแบบเดิมไว้เป็นวิธีการสำรองที่เชื่อถือได้และใช้ได้กับทุกอุปกรณ์เสมอ
• วางแผนสำหรับการกระจาย Fragment ของเวอร์ชันระบบปฏิบัติการ: ลักษณะการทำงานของพาสคีย์อาจแตกต่างกันไปในแต่ละระบบปฏิบัติการ ทดสอบอย่างละเอียดใน Android 13, 14 และ 15 ขึ้นไป และพิจารณาความแตกต่างเฉพาะ OEM ใน UI การเลือกข้อมูลเข้าสู่ระบบ
• ขายอัปเซลตามบริบทและให้ความรู้: แสดงการสร้างพาสคีย์อย่างเป็นธรรมชาติในระหว่างการดำเนินการที่เกี่ยวข้องกับความปลอดภัย เน้นคุณค่าที่นำเสนอ (ความเร็วและความปลอดภัย) อย่างชัดเจนโดยใช้ภาษาที่เข้าใจง่ายเพื่อกระตุ้นให้ผู้ใช้หันมาใช้ฟีเจอร์นี้
• ตรวจสอบในเชิงรุก: ระบบนิเวศจะพัฒนาไปพร้อมกับการอัปเดตระบบปฏิบัติการแต่ละครั้ง ติดตามรูปแบบเวลาในการตอบสนองและข้อผิดพลาดอย่างต่อเนื่องเพื่อรับมือกับภูมิทัศน์ของอุปกรณ์ที่เปลี่ยนแปลงไป

เริ่มต้นใช้งานพาสคีย์และ Credential Manager

ทดลองใช้พาสคีย์และ Credential Manager ใน Android โดยใช้คู่มือการผสานรวมและโค้ดตัวอย่างสาธารณะ

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