Kiểm thử trình quản lý mật khẩu cho passkey trên ứng dụng gốc

1. Giới thiệu: Passkey trên ứng dụng gốc kết hợp với trình quản lý mật khẩu bên thứ ba#

Với việc phát hành iOS 17 và Android 14, bối cảnh passkey dành cho các ứng dụng di động gốc đã thay đổi căn bản. Lần đầu tiên, các trình quản lý mật khẩu bên thứ ba có thể đóng vai trò là nhà cung cấp passkey, phá vỡ sự độc quyền của iCloud Keychain và Google Password Manager. Điều này cho phép người dùng mang các giải pháp đáng tin cậy của riêng họ như 1Password, Bitwarden hoặc Dashlane vào các quy trình xác thực ứng dụng gốc. Dù đây là một thắng lợi lớn cho sự lựa chọn của người dùng, nó lại đưa đến sự phức tạp đáng kể cho các nhà phát triển. Việc triển khai passkey của bạn có thể hoạt động khác nhau trên các trình quản lý mật khẩu khác nhau trong các ứng dụng di động gốc. Do đó, điều quan trọng đối với bất kỳ đội ngũ nào là phải kiểm thử passkey trên ứng dụng gốc và các trình quản lý mật khẩu bên thứ ba một cách hợp lý.

Hướng dẫn toàn diện này chia sẻ phương pháp tiếp cận đã được kiểm chứng của chúng tôi để kiểm thử passkey trên ứng dụng gốc với các trình quản lý mật khẩu bên thứ ba. Mặc dù hệ sinh thái passkey đã trưởng thành đáng kể vào năm 2025, việc triển khai trong thế giới thực vẫn đòi hỏi phải xác minh cẩn thận trên nhiều triển khai trình quản lý mật khẩu khác nhau. Chúng tôi đã chắt lọc kinh nghiệm của mình thành một kế hoạch kiểm thử thực tế nhằm đảm bảo ứng dụng gốc của bạn hoạt động liền mạch với các trình quản lý mật khẩu yêu thích của người dùng.

2. Tại sao việc kiểm thử passkey lại quan trọng trên môi trường Production#

2.1 Người dùng tự mang theo trình quản lý mật khẩu của riêng họ#

Hệ sinh thái trình quản lý mật khẩu đã phát triển vượt ra ngoài các giải pháp gốc của nền tảng. Người dùng chủ động lựa chọn các trình quản lý mật khẩu bên thứ ba như 1Password, Bitwarden, Dashlane, Proton Pass và NordPass dựa trên nhu cầu cụ thể của họ, chẳng hạn như đồng bộ hóa đa nền tảng, các tính năng dành cho doanh nghiệp hoặc tùy chọn quyền riêng tư. Ứng dụng iOS / Android gốc của bạn phải thích ứng với sự đa dạng này mà không ép buộc người dùng chuyển đổi giải pháp quản lý mật khẩu tin cậy của họ.

Dựa trên dữ liệu chúng tôi đo lường qua các trang của Corbado, chúng tôi thấy rằng chỉ có 5-10% người dùng phổ thông dựa vào các trình quản lý mật khẩu bên thứ ba. Dù con số này nghe có vẻ thấp, nó sẽ có tác động lớn đến nhận thức về việc triển khai passkey của bạn và số lượng yêu cầu hỗ trợ nếu bạn đang làm việc trong môi trường quy mô lớn. Chúng tôi đã thấy rằng một số trình quản lý mật khẩu triển khai đặc tả WebAuthn hơi khác nhau, dẫn đến các biến thể nhỏ trong trải nghiệm người dùng hoặc thậm chí là lỗi.

2.2 Các mô hình UX khác nhau trong ứng dụng gốc#

Các ứng dụng iOS và Android gốc cung cấp nhiều cách khác nhau để sử dụng passkey. Trên Android, bạn sẽ bắt gặp các overlay passkey và thao tác nhập trường văn bản thủ công để kích hoạt quá trình thiết lập passkey (đối với ứng dụng web, Android cũng hỗ trợ Conditional UI). iOS cung cấp một bộ overlay passkey riêng biệt cùng với Conditional UI và cả việc nhập trường văn bản thủ công. Hơn nữa, còn có các trường hợp ngoại lệ khác cần kiểm tra. Tóm lại, ứng dụng gốc của bạn phải xử lý một cách trơn tru:

• Đăng nhập bằng overlay passkey xuất hiện ngay khi tải trang
• Đăng nhập bằng Conditional UI (chỉ trên iOS) tự động đề xuất các passkey khả dụng
• Đăng nhập bằng trường văn bản nơi người dùng cung cấp tên người dùng của họ trước khi nhấp vào nút
• Xác thực chéo thiết bị (CDA) để sử dụng passkey với thiết bị khác
• Các cơ chế dự phòng khi không thể sử dụng passkey

2.3 Các cờ WebAuthn đòi hỏi sự chính xác#

Việc cấu hình cờ chính xác xác định liệu các passkey có hoạt động như mong đợi trên các thiết bị và nền tảng hay không. Các giá trị quan trọng bao gồm:

• Relying Party ID (rpID): Phải khớp chính xác trên cả việc triển khai web và ứng dụng gốc, và là miền mà passkey bị ràng buộc
• Xác minh người dùng (User verification): Xác định rằng người dùng cần cung cấp xác thực cục bộ của họ
• Khóa thường trú/thông tin xác thực có thể khám phá (Resident key/discoverable credentials): Bật tính năng xác thực không cần tên người dùng (cho phép Conditional UI)
• Điều kiện sao lưu (BE) và trạng thái sao lưu (BS): Cho phép đồng bộ hóa passkey giữa các thiết bị

Các cờ bị cấu hình sai không phải lúc nào cũng gây ra lỗi ngay lập tức. Tuy nhiên, chúng có thể tạo ra các vấn đề nhỏ và sự không nhất quán, chẳng hạn như passkey khả dụng trên một thiết bị nhưng không đồng bộ hóa trên các thiết bị khác (ngay cả khi cùng một trình quản lý mật khẩu bên thứ ba có thể khả dụng trên cả hai thiết bị). Một trong những phát hiện của chúng tôi trong quá trình kiểm thử là một số trình quản lý mật khẩu bên thứ ba thiết lập sai các cờ BE/BS, và điều này là nguyên nhân cho phần lớn các sự cố về passkey.

2.4 Quản lý vòng đời trong các ứng dụng Single-Instance#

Các kiến trúc một hoạt động (Android) và một cảnh (iOS) yêu cầu quản lý vòng đời cực kỳ tỉ mỉ. Khi một bảng tính (sheet) trình quản lý mật khẩu xuất hiện và bị loại bỏ, ứng dụng của bạn phải bảo toàn trạng thái, xử lý các lệnh gọi lại (callback) và tiếp tục một cách chính xác. Điều này đặc biệt quan trọng trên Android, nơi cấu hình launchMode có thể gây ra hành vi không mong muốn.

Ví dụ, chúng tôi phát hiện ra rằng việc thiết lập MainActivity thành launchMode="singleInstance" đã tạo ra sự cố. Trên một số phiên bản Android và tùy biến của nhà sản xuất (OEM), chế độ này khiến giao diện Passkey Credential Manager mở dưới dạng một tác vụ riêng biệt. Điều này không chỉ thêm một mục ứng dụng bổ sung gây nhầm lẫn vào màn hình "Recents" mà còn có thể khiến ứng dụng bị treo nếu chạy nền trong khi hộp thoại passkey đang mở.

Bản sửa lỗi được khuyến nghị là thay đổi cấu hình thành launchMode="singleTask". Thao tác này ngăn Credential Manager tạo ra một tác vụ riêng biệt, đảm bảo vòng đời dễ đoán hơn trên các OEM khác nhau (Samsung, Google, Vivo, v.v.) và giảm rủi ro về các lỗi dành riêng cho nhà cung cấp. Nó cung cấp một nền tảng ổn định hơn để kiểm tra điều hướng, các overlay và liên kết sâu (deeplink).

Chúng tôi đã quan sát thấy rằng các sự cố vòng đời như vậy thường ngụy trang thành "lỗi trình quản lý mật khẩu" trong khi chúng thực chất là vấn đề ở cấp độ ứng dụng. Việc giám sát và kiểm thử thích hợp trên các nhà cung cấp khác nhau giúp xác định sớm các mô hình này.

3. Thiết lập môi trường kiểm thử của bạn#

3.1 Các trình quản lý mật khẩu mục tiêu#

Tập trung việc kiểm thử passkey trên ứng dụng gốc của bạn vào các trình quản lý mật khẩu bên thứ ba được sử dụng rộng rãi nhất:

Các mục tiêu chính (bảo đảm phạm vi thiết yếu):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Các mục tiêu thứ cấp (dựa trên cơ sở người dùng của bạn):

• Nhà cung cấp khu vực (ví dụ: Samsung Pass cho thiết bị Samsung)
• Các giải pháp doanh nghiệp nếu nhắm mục tiêu đến người dùng doanh nghiệp
• Các mặc định của nền tảng (Google Password Manager, iCloud Keychain) làm cơ sở

Tránh xu hướng kiểm thử mọi trình quản lý mật khẩu có sẵn. Hãy tập trung vào các nhà cung cấp đại diện cho 90% cơ sở người dùng của bạn. Phân tích của chúng tôi cho thấy rằng 5 mục tiêu chính chiếm tới 85% lượng người dùng trình quản lý mật khẩu bên thứ ba tại khu vực EU/Mỹ/Anh/Úc/New Zealand.

3.2 Danh sách kiểm tra trước khi tiến hành#

Trước khi bắt đầu mỗi lần chạy kiểm thử, hãy đảm bảo một môi trường sạch, có thể tái lập:

1. Trạng thái thông tin xác thực sạch:

• Xóa tất cả các thông tin xác thực hiện có đối với RP ID của bạn
• Xóa bộ nhớ đệm ứng dụng và trình duyệt
• Đăng xuất hoàn toàn và đăng nhập lại vào trình quản lý mật khẩu
• Buộc đóng (force-close) và khởi chạy lại ứng dụng mục tiêu

2. Ổn định môi trường kiểm thử:

• Đảm bảo kết nối mạng ổn định (không dùng VPN trong quá trình kiểm thử)
• Tắt hiệu ứng hoạt hình giao diện người dùng (UI animations) nếu kiểm thử tự động
• Sử dụng hướng thiết bị nhất quán
• Ghi chép tài liệu về phiên bản OS, phiên bản ứng dụng và phiên bản trình quản lý mật khẩu

4. Kế hoạch kiểm thử toàn diện#

Mỗi bài kiểm thử nhằm xác minh các khía cạnh cụ thể của tính năng passkey. Hãy ghi chép kết quả một cách có hệ thống bằng cách sử dụng trạng thái đạt/không đạt (pass/fail) và các ghi chú chi tiết về bất kỳ điều gì bất thường.

4.1 Các bài kiểm thử luồng xác thực cốt lõi#

Bài kiểm thử 1: Hủy tạo Passkey (sau khi đăng nhập truyền thống thành công)#

Xác minh việc xử lý hủy bỏ một cách trơn tru

✓ Bảng (sheet) trình quản lý mật khẩu mở chính xác
✓ Người dùng hủy mà không tạo passkey
✓ Ứng dụng quay lại màn hình đăng nhập
✓ Không có thông tin xác thực bị mồ côi (orphaned credentials) trong trình quản lý mật khẩu
✓ Giao diện hiển thị các tùy chọn thử lại phù hợp

Bài kiểm thử 2: Tạo Passkey (sau khi đăng nhập truyền thống thành công)#

Xác minh việc tạo passkey sau luồng xác thực

✓ Xác thực cục bộ được khởi chạy đáng tin cậy
✓ Xác thực sinh trắc học hoàn tất thành công
✓ Thông tin xác thực được tạo với RP ID chính xác
✓ Ứng dụng chuyển sang trạng thái đã xác thực mà không bị lặp vòng

Bài kiểm thử 3: Xác thực với Passkey hiện có#

Kiểm thử các tình huống xác thực tiêu chuẩn

✓ Giao diện Overlay Passkey xuất hiện hoặc người dùng cung cấp tên đăng nhập trong tình huống trường văn bản
✓ Quét sinh trắc học và nhắc nhở sinh trắc học đơn lẻ dẫn đến việc xác thực thành công
✓ Không có vòng lặp chọn lựa hoặc bảng chọn xuất hiện lại
✓ Phiên làm việc vẫn ổn định sau khi xác thực

Bài kiểm thử 4: Tạo Passkey từ Cài đặt#

Xác minh khả năng quản lý passkey trong ứng dụng

✓ RP ID chính xác, khả năng khám phá và các cờ BE/BS
✓ Ứng dụng vẫn được xác thực sau khi tạo
✓ Trình quản lý mật khẩu cập nhật ngay lập tức với nhãn chính xác

Bài kiểm thử 5: Xóa passkey và thử đăng nhập lại#

Kiểm thử quản lý vòng đời thông tin xác thực

✓ Xóa passkey trong cài đặt
✓ Đăng nhập bằng passkey không thể thực hiện được
✓ Tùy chọn dự phòng phù hợp được cung cấp

4.2 Các bài kiểm thử tương thích đa nền tảng#

Bài kiểm thử 6: Sử dụng Passkey được tạo gốc (native) trên Web (Cùng thiết bị)#

Xác minh tính di động từ ứng dụng sang web

✓ Trình duyệt nhận diện được các passkey được tạo trên ứng dụng
✓ Bảng chọn hiển thị liên kết RP chính xác
✓ Quá trình xác thực hoàn tất mà không cần phải đi qua mã QR/CDA

Bài kiểm thử 7: Sử dụng Passkey được tạo trên Web trong ứng dụng gốc#

Kiểm thử chia sẻ thông tin xác thực từ web sang ứng dụng

✓ Ứng dụng đưa lên trên cùng thông tin xác thực được tạo trên web trong lựa chọn
✓ Xác thực thành công trong lần thử đầu tiên
✓ Không có dự phòng bắt buộc bằng mật khẩu

Bài kiểm thử 8: Đồng bộ hóa thiết bị chéo (Di động lên Máy tính để bàn)#

Xác minh quá trình đồng bộ passkey từ ứng dụng gốc sang trình duyệt máy tính

✓ Passkey được tạo trên ứng dụng đồng bộ hóa với trình quản lý mật khẩu trên máy tính
✓ Passkey đã được đồng bộ hóa hoạt động mượt mà trong trình duyệt máy tính
✓ Không kích hoạt mã QR / quy trình chéo thiết bị
✓ Quá trình xác thực hoàn tất mà không có vòng lặp hay lỗi

Bài kiểm thử 9: Đồng bộ hóa thiết bị chéo (Máy tính để bàn sang Di động)#

Xác minh quá trình đồng bộ passkey từ trình duyệt máy tính sang ứng dụng gốc

✓ Passkey được tạo trên máy tính đồng bộ với trình quản lý mật khẩu trên thiết bị di động
✓ Ứng dụng gốc đưa passkey đã đồng bộ lên trên cùng một cách chính xác
✓ Xác thực thành công mà không cần dùng đến mật khẩu dự phòng
✓ Log nối kết việc xác nhận với ID thông tin xác thực chính xác

Bài kiểm thử 10: Sử dụng Di động làm trình xác thực (Authenticator) cho Web#

Xác minh tình huống dùng điện thoại như một khóa bảo mật

✓ Điện thoại cung cấp thông tin xác thực được tạo trên ứng dụng cho web CDA
✓ Không có thông báo lỗi "không có passkey nào khả dụng" sai lệch
✓ Phiên làm việc web hoàn tất sau khi xác thực sinh trắc học trên thiết bị di động

5. Các vấn đề phổ biến và Chiến lược giảm thiểu rủi ro#

Quá trình kiểm thử mở rộng của chúng tôi đã tiết lộ một số khuôn mẫu lặp lại gây ảnh hưởng đến việc tích hợp passkey cho trình quản lý mật khẩu bên thứ ba:

Độ trễ đồng bộ hóa thiết bị chéo#

Vấn đề: Thông tin xác thực được tạo trên một thiết bị có thể không xuất hiện ngay lập tức trên các thiết bị khác.

Giải pháp: Thực hiện logic thử lại (retry logic) kết hợp với exponential backoff. Cung cấp tùy chọn làm mới thủ công cho người dùng gặp phải độ trễ đồng bộ hóa.

Các hành vi phụ thuộc vào phiên bản#

Vấn đề: Hành vi của trình quản lý mật khẩu khác nhau đáng kể giữa các phiên bản OS, đặc biệt trên Android 14+ và iOS 17+.

Giải pháp: Duy trì một ma trận tương thích và điều chỉnh luồng dựa trên phiên bản hệ điều hành phát hiện được. Cân nhắc các yêu cầu phiên bản tối thiểu để đảm bảo trải nghiệm tối ưu.

6. Kết luận: Xây dựng hỗ trợ Passkey sẵn sàng cho Production#

Việc triển khai thành công hỗ trợ passkey qua trình quản lý mật khẩu bên thứ ba trong các ứng dụng gốc đòi hỏi quá trình kiểm thử bài bản và chú ý đến chi tiết. Kế hoạch kiểm thử toàn diện của chúng tôi, được tinh chỉnh thông qua thực tiễn, cung cấp nền tảng vững chắc cho việc xác minh tính năng passkey được tích hợp của bạn.

Những điểm chính cần nắm bắt để triển khai trên môi trường production:

1. Kiểm thử một cách có hệ thống: Sử dụng kế hoạch kiểm thử của chúng tôi làm mốc tham chiếu cơ sở, thích ứng với các tình huống sử dụng cụ thể của bạn
2. Tôn trọng sự lựa chọn của người dùng: Hỗ trợ các trình quản lý mật khẩu mà người dùng ưa thích thay vì chỉ có các mặc định của nền tảng
3. Giám sát liên tục: Thực hiện ghi nhật ký (logging) toàn diện để bắt các trường hợp ngoại lệ trong quá trình vận hành
4. Viết tài liệu kỹ lưỡng: Lưu lại hồ sơ rõ ràng về các hành vi đặc thù và giải pháp xử lý của các nhà cung cấp

Hệ sinh thái passkey đang không ngừng phát triển mạnh mẽ. Các trình quản lý mật khẩu thường xuyên cập nhật bản triển khai, các hệ điều hành giới thiệu các tính năng mới và đặc tả WebAuthn cũng liên tục cải tiến. Bằng cách thiết lập ngay một bộ khung kiểm thử vững chắc, bạn sẽ có sự chuẩn bị tốt để thích nghi khi công nghệ ngày càng hoàn thiện.

Chúng tôi sẽ tiếp tục cập nhật SDK và phương pháp kiểm thử khi có những mô hình hoạt động mới xuất hiện. Việc đầu tư vào kiểm thử toàn diện trình quản lý mật khẩu bên thứ ba sẽ mang lại lợi ích về việc giảm bớt gánh nặng cho bộ phận hỗ trợ và cải thiện sự hài lòng của người dùng. Xét cho cùng, quá trình xác thực cần phải diễn ra suôn sẻ — bất kể người dùng của bạn chọn sử dụng trình quản lý mật khẩu nào.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Câu hỏi thường gặp#

Tôi nên ưu tiên những trình quản lý mật khẩu bên thứ ba nào khi kiểm thử passkey trên ứng dụng gốc?#

Hãy ưu tiên 1Password, Bitwarden, Dashlane, Proton Pass và NordPass làm các mục tiêu chính. Năm nhà cung cấp này bao phủ 85% người dùng trình quản lý mật khẩu bên thứ ba tại các thị trường EU/Mỹ/Anh/Úc/New Zealand, mang lại độ bao phủ rộng mà không cần đầu tư quá nhiều vào các nhà cung cấp ít phổ biến.

Tại sao các passkey được tạo trong ứng dụng gốc lại không thể đồng bộ hóa trên các thiết bị khi sử dụng trình quản lý mật khẩu bên thứ ba?#

Việc cấu hình sai cờ điều kiện sao lưu (BE) và trạng thái sao lưu (BS) là nguyên nhân hàng đầu gây ra lỗi đồng bộ hóa chéo giữa các thiết bị. Một số trình quản lý mật khẩu bên thứ ba thiết lập các cờ này không chính xác, khiến passkey tồn tại trên một thiết bị nhưng không đồng bộ hóa với thiết bị khác ngay cả khi đã cài đặt cùng một trình quản lý mật khẩu trên cả hai.

Làm thế nào để khắc phục lỗi giao diện Credential Manager trên Android hiển thị dưới dạng các tác vụ riêng biệt trong màn hình Recents?#

Việc thiết lập MainActivity thành launchMode singleInstance khiến giao diện Credential Manager xuất hiện như một tác vụ riêng biệt, tạo ra mục nhập lộn xộn trong màn hình Recents và có khả năng làm treo ứng dụng khi chạy nền. Thay đổi cấu hình thành launchMode singleTask sẽ giải quyết vấn đề này trên các nhà sản xuất thiết bị như Samsung, Google và Vivo.

Tôi phải kiểm thử các quy trình xác thực nào khi xác minh hỗ trợ trình quản lý mật khẩu bên thứ ba trong ứng dụng iOS hoặc Android gốc?#

Một kế hoạch kiểm thử toàn diện bao gồm 10 tình huống: tạo passkey và hủy bỏ một cách trơn tru, xác thực qua overlay và trường văn bản, quản lý thông tin xác thực trong ứng dụng, xóa thông tin xác thực với cơ chế dự phòng và đồng bộ hóa hai chiều giữa các thiết bị. Các bài kiểm thử đa nền tảng cũng nên xác nhận rằng passkey được tạo trên ứng dụng có thể xác thực trong trình duyệt và passkey được tạo trên web có thể xác thực trong ứng dụng gốc.