Trang này được dịch tự động. Đọc phiên bản gốc bằng tiếng Anh tại đây.
Tải xuống miễn phí toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey và nhận quyền truy cập vào tất cả các thông tin chuyên sâu.
Mua hay Tự xây dựng một giải pháp Passkey?
Nhận danh sách kiểm tra đầy đủ cho việc triển khai passkey, so sánh các giải pháp tự làm so với nhà cung cấp (SaaS & on-prem), các thách thức chính, chi phí và các phương pháp hay nhất.

Ý tưởng tự xây dựng bản triển khai passkey nghe có vẻ hấp dẫn: kiểm soát hoàn toàn, tích hợp tùy chỉnh và không bị phụ thuộc vào nhà cung cấp. Xét cho cùng, FIDO2 dựa trên các tiêu chuẩn mở và việc viết những dòng mã WebAuthn đầu tiên dường như khá dễ dàng. Nó thực sự khó đến mức nào?
Nhưng đây thường là nơi bắt đầu của sự phức tạp, đặc biệt là khi bạn có kế hoạch xây dựng một giải pháp cho kịch bản triển khai quy mô lớn cho hàng triệu người tiêu dùng trong các ngành như:
Thách thức thực sự bắt đầu sau lần đăng nhập passkey thành công đầu tiên và thường chỉ lộ diện trong khi bạn đang triển khai giải pháp passkey của mình. Đột nhiên, những thứ như các trường hợp ngoại lệ kỳ lạ, lỗi người dùng gây nhầm lẫn và khả năng người dùng bị khóa do sự không khả dụng của passkey xuất hiện. Những gì tưởng chừng như là một sự tích hợp đơn giản lại biến thành nhiều tháng hoặc thậm chí nhiều năm nỗ lực phát triển, chi phí bảo trì không mong muốn và một dự án passkey có khả năng thất bại.
Tuy nhiên, tự xây dựng giải pháp của riêng bạn cũng có thể là sự lựa chọn phù hợp cho một số tổ chức và yêu cầu cụ thể. Chúng tôi đã nói chuyện với hàng chục tổ chức về kế hoạch triển khai passkey của họ và đồng hành cùng một số tổ chức trong hành trình của họ một cách thực tế. Hướng dẫn này sẽ giúp bạn xác định khi nào cách tiếp cận passkey Tự làm (DIY) có thể hợp lý và khi nào việc chọn một nhà cung cấp passkey lâu năm là quyết định thông minh hơn.
Với Hướng dẫn Mua hay Tự xây dựng Passkey của chúng tôi, chúng tôi muốn trả lời các câu hỏi sau:
Mật khẩu đã lỗi thời, không an toàn và gây bực bội. Passkey loại bỏ rủi ro lừa đảo (phishing), cải thiện trải nghiệm người dùng và đơn giản hóa quá trình xác thực - làm cho chúng trở thành tiêu chuẩn mới của đăng nhập an toàn. Cho dù bạn xây dựng nội bộ hay sử dụng giải pháp bên ngoài, việc tích hợp passkey là một bước nâng cấp lớn về bảo mật và khả năng sử dụng.
Google nhận thấy rằng việc bắt đầu với câu chuyện về sự dễ sử dụng hoặc tốc độ sẽ tạo được tiếng vang và mang lại hiệu quả. Mọi người thường cằn nhằn về việc đăng nhập, vì vậy bất cứ điều gì làm cho quá trình này dễ dàng và nhanh chóng hơn đều là một chiến thắng.
Bên cạnh những lợi ích bảo mật này, có tiềm năng rất lớn để tiết kiệm chi phí hoạt động với passkey. Bạn có thể giảm số lượng SMS OTP được gửi cho người dùng, điều này có thể tích tụ rất lớn đối với các cơ sở người dùng quy mô lớn. Hơn nữa, gánh nặng mà việc khôi phục mật khẩu và MFA đặt lên đội ngũ hỗ trợ khách hàng của bạn cũng là một yếu tố chi phí có thể được loại bỏ.
Ngoài ra, passkey cải thiện tỷ lệ đăng nhập thành công và thời gian đăng nhập cho người dùng, cuối cùng dẫn đến tỷ lệ chuyển đổi tốt hơn, đây là động lực chính cho sự tăng trưởng doanh thu ở các ngành như thương mại điện tử, bán lẻ hoặc du lịch.
Mục tiêu cuối cùng của nhiều tổ chức khi xem xét việc áp dụng passkey là tiến tới hoàn toàn không sử dụng mật khẩu. Để đạt được mục tiêu này, thường có bốn giai đoạn cần hoàn thành. Tốc độ tiến triển của các giai đoạn này phụ thuộc phần lớn vào khả năng kỹ thuật, mô hình đăng nhập và cơ sở người dùng của tổ chức. Trong một số trường hợp, các yếu tố bên ngoài như áp lực từ công chúng trong việc áp dụng xác thực an toàn hơn hoặc các hạn chế tài chính cũng có thể đóng một vai trò.
Hãy cùng xem xét và mô tả bốn giai đoạn này, vì việc triển khai passkey chỉ là một bước trong việc đảm bảo thành công của một dự án passkey.
Bước đầu tiên trong quá trình chuyển đổi sang một hệ thống hoàn toàn không mật khẩu là tích hợp passkey làm một phương thức đăng nhập. Ở giai đoạn này, mật khẩu và các phương thức xác thực khác vẫn được giữ lại làm phương án dự phòng để đảm bảo người dùng vẫn có thể truy cập tài khoản của họ nếu họ chưa áp dụng passkey. Tích hợp thành công đòi hỏi khả năng tương thích liền mạch với các luồng đăng nhập hiện có và chính sách bảo mật. Các tổ chức nên tập trung vào việc làm cho việc tạo passkey trở nên đơn giản, đảm bảo rằng cả người dùng kỹ thuật và không am hiểu kỹ thuật đều có thể áp dụng phương thức xác thực mới mà không gặp rào cản nào.
Igor Gjorgjioski
Head of Digital Channels & Platform Enablement, VicRoads
We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.
See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.
Read the case studyKhi passkey đã được tích hợp, thách thức tiếp theo là thúc đẩy người dùng áp dụng passkey. Nhiều tổ chức đánh giá thấp tầm quan trọng của giai đoạn này, nhưng nếu không có sự áp dụng rộng rãi của người dùng, một dự án passkey rất có thể sẽ thất bại. Mục tiêu là khuyến khích càng nhiều người dùng càng tốt tạo và sử dụng passkey, lý tưởng nhất là biến chúng thành phương thức đăng nhập mặc định.
Các chiến thuật chính để tăng cường sự áp dụng bao gồm giáo dục người dùng một cách chủ động, các gợi ý (nudge) trên giao diện người dùng để thúc đẩy việc tạo passkey và các chương trình ưu đãi thưởng cho người dùng chuyển đổi. Các tổ chức nên thiết lập một ngưỡng áp dụng quan trọng, chẳng hạn như 50-80% người dùng hoạt động sử dụng passkey, trước khi chuyển sang giai đoạn tiếp theo. Để hiểu sâu hơn về lý do tại sao sự áp dụng lại quan trọng, hãy tham khảo bài viết chuyên sâu của chúng tôi về cách tỷ lệ áp dụng kém có thể gây nguy hiểm cho dự án passkey của bạn.
Khi việc áp dụng passkey đạt đến một khối lượng tới hạn, các tổ chức có thể bắt đầu loại bỏ dần mật khẩu. Tuy nhiên, việc loại bỏ mật khẩu quá sớm hoặc không có kế hoạch cẩn thận có thể dẫn đến các vấn đề về khả năng sử dụng và gia tăng yêu cầu hỗ trợ. Nên áp dụng phương pháp theo từng giai đoạn:
Bằng cách hướng dẫn người dùng một cách có chiến lược hướng tới xác thực hoàn toàn không mật khẩu, các tổ chức có thể tối đa hóa bảo mật mà không làm gián đoạn trải nghiệm người dùng.
Sau khi mật khẩu bị loại bỏ, các cơ chế khôi phục tài khoản phải trở nên mạnh mẽ và an toàn. Các phương pháp khôi phục truyền thống thường dựa vào các can thiệp thủ công, chẳng hạn như phiếu hỗ trợ (support ticket) hoặc đặt lại qua email, có thể gây ra rủi ro bảo mật và chi phí hoạt động. Các tổ chức phải triển khai các giải pháp khôi phục tài khoản tự phục vụ, hiện đại để duy trì bảo mật đồng thời cải thiện trải nghiệm người dùng.
Các yếu tố chính của việc khôi phục tài khoản tự động bao gồm:
Nhiều tổ chức đã tự đầu tư vào các quy trình khôi phục tự động độc lập với quá trình chuyển đổi không mật khẩu của họ để giảm chi phí và nâng cao khả năng sử dụng. Tuy nhiên, trong một hệ sinh thái dựa trên passkey, các cơ chế này càng trở nên quan trọng hơn để duy trì bảo mật và giảm thiểu ma sát.
Dựa trên bốn giai đoạn này, giờ đây chúng tôi sẽ cố gắng giúp bạn đánh giá quyết định mua hay tự xây dựng. Do đó, điều rất quan trọng đối với thành công lâu dài của dự án passkey của bạn là phải ghi nhớ tất cả các giai đoạn và không chỉ tích hợp passkey (đây vẫn có thể là một mục tiêu nhưng sau đó bạn bỏ lỡ toàn bộ tiềm năng của passkey).
Việc lựa chọn giữa giải pháp DIY và giải pháp passkey bên ngoài phụ thuộc vào nguồn lực kỹ thuật, ưu tiên bảo mật, quy mô triển khai và chiến lược passkey dài hạn của công ty bạn. Trong phần tiếp theo, chúng tôi sẽ phân tích các khía cạnh chính để giúp bạn đưa ra quyết định tốt nhất.
Bảng sau hiển thị các tiêu chí đánh giá khác nhau mà bạn cần xem xét. Dựa trên nhận định mà bạn nghiêng về hơn, các số điểm khác nhau sẽ được cung cấp.
Cách sử dụng ma trận đánh giá:
Đối với mỗi tiêu chí, hãy chọn xem công ty của bạn cần một giải pháp đơn giản hơn hay phức tạp hơn.
Tải xuống miễn phí toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey và nhận quyền truy cập vào tất cả các tiêu chí đánh giá.
Mua hay Tự xây dựng một giải pháp Passkey?
Nhận danh sách kiểm tra đầy đủ cho việc triển khai passkey, so sánh các giải pháp tự làm so với nhà cung cấp (SaaS & on-prem), các thách thức chính, chi phí và các phương pháp hay nhất.

Khi quyết định nên xây dựng hay mua một giải pháp passkey, điều quan trọng là phải xem xét toàn bộ quy trình, không chỉ một giai đoạn duy nhất của việc triển khai passkey. Ngay cả khi ưu tiên trong thời gian tới của bạn là cung cấp passkey dưới dạng MVP, bạn vẫn nên lường trước những tác động dài hạn, đặc biệt là việc thúc đẩy sự áp dụng. Dưới đây là cách chúng tôi khuyên bạn nên sử dụng hướng dẫn này và diễn giải kết quả của bạn, nhấn mạnh lý do tại sao sự áp dụng lại quan trọng hơn hầu hết mọi yếu tố khác.
Cho dù giải pháp passkey của bạn tiên tiến đến đâu, nếu người dùng không áp dụng nó bằng cách tạo passkey và sử dụng passkey để đăng nhập, toàn bộ dự án sẽ gặp rủi ro. Theo kinh nghiệm của chúng tôi, các tổ chức thường đánh giá thấp nỗ lực cần thiết để di chuyển người dùng khỏi mật khẩu. Ngay cả khi bạn triển khai passkey một cách liền mạch ở cấp độ kỹ thuật, sự áp dụng thấp sẽ dẫn đến:
Sự áp dụng cao, đôi khi là 50% hoặc thậm chí +80% cơ sở người dùng của bạn, thường được yêu cầu trước khi bạn có thể đạt được những bước tiến có ý nghĩa hướng tới việc giảm hoặc loại bỏ hoàn toàn mật khẩu. Các tổ chức như Google và Amazon đặt ra các mục tiêu áp dụng rõ ràng và thực hiện một cách có hệ thống các thử nghiệm A/B, chiến dịch giáo dục người dùng và các gợi ý trên giao diện người dùng (UI nudges) để đảm bảo passkey được đón nhận rộng rãi. Sự nỗ lực tập trung này vào việc áp dụng không phải là tùy chọn; đó là điều biến việc triển khai passkey của bạn từ một tính năng thành một lợi thế cạnh tranh thiết thực.
Hướng dẫn này được thiết kế để giúp bạn đưa ra những quyết định sáng suốt về việc triển khai passkey ở mọi giai đoạn của hành trình:
Trong số này, Giai đoạn 2 (Tăng cường Sự áp dụng) là quan trọng nhất. Bạn có thể đánh giá riêng từng phần, nhưng hãy nhớ rằng thành công dài hạn và ROI của bạn thường phụ thuộc vào mức độ nghiêm túc của bạn đối với việc áp dụng ngay từ đầu.
Nếu bạn đang ở giai đoạn đầu của việc quyết định triển khai passkey, hãy bắt đầu với phần đầu tiên của ma trận đánh giá (tích hợp passkey) và điền vào đó với ban quản lý, IT, chủ sở hữu sản phẩm (product owner) và các nhà ra quyết định chính khác. Hãy tự hỏi bản thân:
Việc trả lời những câu hỏi này ngay từ đầu đảm bảo dự án passkey của bạn không đi vào ngõ cụt. Các tổ chức không lập kế hoạch cho việc áp dụng thường thấy mình bị mắc kẹt với mật khẩu trong nhiều năm tới, làm suy yếu toàn bộ chiến lược bảo mật và trải nghiệm người dùng.
Trong toàn bộ ma trận, mỗi tiêu chí đánh giá có thể đưa bạn từ mức độ phức tạp thấp nhất (1) đến mức độ phức tạp cao nhất (5). Càng nhiều câu trả lời của bạn chuyển sang và vượt qua vùng trung lập (3), thì trường hợp sử dụng nhà cung cấp passkey chuyên biệt càng mạnh mẽ:
Những yếu tố này có thể làm quá tải các nhóm nội bộ, cả về kỹ thuật lẫn tổ chức. Một giải pháp passkey được quản lý thường có thể cung cấp các phương pháp hay nhất đã được chứng minh, các bản cập nhật nhanh chóng và chuyên môn trong thế giới thực để tăng tốc độ áp dụng nhanh hơn nhiều so với cách tiếp cận DIY.
Là một chuyên gia về passkey, chúng tôi tại Corbado có một quan điểm mạnh mẽ. Nếu passkey nằm trên lộ trình của bạn và bạn muốn một bản triển khai hiện đại giúp tích cực thúc đẩy sự áp dụng, Corbado Connect có thể giúp bạn giải quyết sự phức tạp ở quy mô lớn. Dưới đây là lý do tại sao:
Sự áp dụng được tích hợp vào giải pháp: Nền tảng của chúng tôi được thiết kế xoay quanh việc tối đa hóa sự chọn tham gia (opt-in) của người dùng thông qua các gợi ý thông minh, phân tích và thử nghiệm A/B liên tục, điều này cũng thúc đẩy việc tiết kiệm chi phí.
Các Bước Tiếp Theo:
Bằng cách giải quyết passkey một cách toàn diện và biến sự áp dụng thành một trong những mục tiêu chính, bạn sẽ đạt được kết quả tốt nhất. Điều đó có nghĩa là bảo mật mạnh mẽ hơn, đăng nhập đơn giản hơn và một con đường thực sự hướng tới tương lai không mật khẩu. Nếu bạn quan tâm đến việc tìm hiểu thêm về Corbado Connect và cách chúng tôi giúp khách hàng đạt được sự áp dụng passkey cao, chúng tôi luôn sẵn sàng trò chuyện.
Bây giờ chúng tôi đã giúp xác định phương pháp tiếp cận đúng đắn để trả lời câu hỏi "Mua hay Tự xây dựng?", chúng tôi sẽ phân tích cách đánh giá sự thành công của một lần triển khai passkey. Do đó, chúng tôi định nghĩa các KPI đầu vào và đầu ra của một dự án passkey.
Các KPI đầu vào giúp theo dõi sự áp dụng ở giai đoạn đầu của passkey và xem liệu các điều kiện cần thiết cho việc sử dụng rộng rãi có đang được thiết lập hay không. Những chỉ số này xuất hiện trước hành vi đăng nhập thực tế nhưng rất quan trọng để kích hoạt sự áp dụng có ý nghĩa và tối ưu hóa quá trình triển khai.
| KPI | Định nghĩa | Tại sao nó quan trọng | Cách Đo lường | Mốc chuẩn (Benchmark) |
|---|---|---|---|---|
| Tỷ lệ Chấp nhận Passkey (Passkey Acceptance Rate) | Tỷ lệ người dùng, sau khi đăng nhập thành công (post-sign-in), nhận được một "gợi ý" (một dấu nhắc hoặc đề xuất khuyến khích họ thiết lập passkey) và chọn tạo passkey. KPI này đặc biệt đo lường mức độ phản hồi của người dùng đối với các lời nhắc sau khi đăng nhập này, nêu bật hiệu quả của thông điệp gợi ý trong việc thúc đẩy việc tạo passkey. Cách tiếp cận này được coi là hiện đại nhất vì người dùng thường không chủ động tạo passkey thông qua tài khoản hoặc cài đặt quản lý thông tin xác thực. Thay vào đó, passkey được áp dụng thành công nhất khi người dùng được nhắc trực tiếp sau khi đăng nhập, làm cho các gợi ý trở thành động lực chính của việc tạo passkey. Đảm bảo phân biệt giữa gợi ý đầu tiên và các gợi ý sau đó vì tỷ lệ này sẽ giảm xuống. | Sự chấp nhận cao cho thấy sự thuyết phục người dùng và thiết kế gợi ý thành công. Tỷ lệ thấp báo hiệu sự cản trở, thông điệp không rõ ràng hoặc sự ngần ngại của người dùng. | Công thức: (Số người dùng hoàn thành việc tạo passkey sau khi được gợi ý) ÷ (Số người dùng tiếp xúc với gợi ý). Phân khúc theo Hệ điều hành/Trình duyệt/Thiết bị. | 50%-75% ở lần gợi ý đầu tiên, lên đến 85% qua nhiều lần gợi ý trên thiết bị di động. Thấp hơn trên máy tính để bàn. Phụ thuộc nhiều vào cách diễn đạt và cách thực hiện. |
| Tỷ lệ Tạo Passkey Thành công (Passkey Creation Success Rate) | Tỷ lệ người dùng bắt đầu quy trình đăng ký passkey nhưng hoàn thành thành công nó (nghĩa là không từ bỏ). | Cho thấy có bao nhiêu người dùng bỏ cuộc giữa chừng trong quá trình tạo do UX khó hiểu, các sự cố kỹ thuật hoặc người dùng suy nghĩ lại. | Công thức: (Số lượt đăng ký passkey hoàn thành) ÷ (Số lượt thử đăng ký) Phân tích các điểm thất bại theo Hệ điều hành/Trình duyệt/Thiết bị. | Gần mức 100%. |
| Số lượng Passkey Được tạo (Number of Created Passkeys) | Số lượng lũy kế của các passkey mới được tạo trong một khoảng thời gian nhất định (hàng ngày, hàng tuần, hàng tháng). | Một thước đo áp dụng thô thường được coi là KPI bán đầu ra. Phản ánh khối lượng sử dụng passkey và khả năng chuyển đổi đăng nhập trong tương lai rời khỏi mật khẩu. | Công thức: Tổng số tất cả các passkey mới được đăng ký trên các danh mục Hệ điều hành, Trình duyệt, Thiết bị. Theo dõi xu hướng tăng trưởng theo thời gian. Con số tuyệt đối không mang ý nghĩa mà phụ thuộc vào quy mô của cơ sở người dùng. | Một số lượng đáng kể mỗi ngày ngay sau khi triển khai hoàn toàn. |
Các KPI đầu vào này đóng vai trò là các chỉ số dẫn dắt cho sự áp dụng passkey trong tương lai và cho phép các tổ chức tinh chỉnh việc giáo dục người dùng, các luồng UX và việc thực hiện kỹ thuật.
Các KPI đầu ra (OKR) đo lường sự thành công thực tế của việc áp dụng passkey bằng cách đánh giá hành vi người dùng, các cải tiến hoạt động và tác động kinh doanh. Các chỉ số này phản ánh hiệu quả trong thế giới thực của việc triển khai passkey. Tỷ lệ Đăng nhập Passkey là một KPI Đầu ra cốt lõi vì nó trực tiếp phản ánh sự áp dụng và việc sử dụng passkey thực tế. Tỷ lệ đăng nhập passkey ngày càng tăng cho thấy sự giới thiệu thành công và sự ưa thích liên tục của người dùng đối với passkey so với các phương thức xác thực cũ.
| KPI | Định nghĩa | Tại sao nó quan trọng | Cách Đo lường | Mốc chuẩn (Benchmark) |
|---|---|---|---|---|
| Tỷ lệ Kích hoạt Người dùng (User Activation Rate) | Trong số tất cả những người dùng đã thấy ít nhất một gợi ý (có thể là nhiều lời nhắc theo thời gian), tỷ lệ phần trăm những người cuối cùng đã tạo ít nhất một passkey. | Đo lường tổng thể thành công của việc giới thiệu passkey thông qua nhiều lần gợi ý. Người dùng có thể từ chối gợi ý đầu tiên nhưng sẽ chuyển đổi sau đó. | Công thức: (Số người dùng duy nhất đã tạo ≥1 passkey) ÷ (Số người dùng duy nhất đã từng được hiển thị ít nhất một gợi ý) Phân khúc theo Hệ điều hành, trình duyệt, thiết bị để xem ai cuối cùng cũng áp dụng passkey. Một khi đợt triển khai phát triển, các passkey bị xóa cũng phải được phản ánh ở đây. | Hơn 50% trong 12 tháng. Tỷ lệ đăng nhập passkey hội tụ về Tỷ lệ Kích hoạt Người dùng. Nó sẽ phụ thuộc vào thành phần người dùng của bạn. |
| Tỷ lệ Đăng nhập Passkey (Passkey Login Rate) | Tỷ lệ phần trăm của tất cả các sự kiện đăng nhập được hoàn thành bằng cách sử dụng passkey thay vì phương pháp cũ (mật khẩu, SMS OTP, v.v.). | Chứng minh tần suất sử dụng passkey trong thế giới thực. Tỷ lệ đăng nhập thấp liên tục chỉ ra rằng người dùng thích hoặc quay lại sử dụng mật khẩu bất chấp việc ban đầu đã tạo passkey, phản ánh tỷ lệ kích hoạt thấp (vì tỷ lệ đăng nhập cao chỉ có thể xảy ra nếu bản thân sự kích hoạt đã cao), hoặc do việc thực hiện đăng nhập chưa tối ưu không tự động tận dụng các passkey hiện có. | Công thức: (Số lần đăng nhập bằng passkey) ÷ (Tổng số lần đăng nhập) Phân khúc theo Hệ điều hành/trình duyệt/thiết bị hoặc nhóm người dùng. Điều này giúp xác định vị trí các nền tảng hoặc nhóm nhân khẩu học gặp vấn đề với mức độ sử dụng passkey thấp. | Hơn 20% trong vài tuần, hơn 50% trong 12 tháng. (Phụ thuộc nhiều vào cách bạn triển khai) |
| Tỷ lệ Đăng nhập Passkey Thành công (Passkey Login Success Rate) | Tỷ lệ các lần thử đăng nhập bằng passkey kết thúc thành công mà không cần quay lại phương án dự phòng (fallback). | Tiết lộ sự cản trở trong luồng passkey. Tỷ lệ thấp hơn có thể chỉ ra sự nhầm lẫn của người dùng, những ràng buộc về môi trường hoặc sự cố tương thích thiết bị dẫn đến việc phải sử dụng phương án dự phòng. Mức không phải 100% là điều được dự đoán trước, vì người dùng chuyển đổi thiết bị hoặc cố gắng đăng nhập từ các thiết bị không được kết nối. Phụ thuộc nhiều vào mô hình người dùng và thiết bị được sử dụng. | Công thức: (Số lần đăng nhập bằng passkey thành công) ÷ (Số lần thử đăng nhập bằng passkey) Theo dõi các lần thử nghiệm một phần, trong đó người dùng từ bỏ passkey giữa chừng và chuyển sang mật khẩu. | Hơn 95% trên web di động. Hơn 99% trên Ứng dụng Gốc (Native Apps). Tỷ lệ đăng nhập trên máy tính để bàn phụ thuộc vào số lượng người dùng của bạn có nhiều thiết bị và nơi họ đăng ký đầu tiên. |
| Thời gian Đăng nhập Passkey so với Đăng nhập Cũ (Passkey Login Time vs. Legacy Login Time) | So sánh thời gian trung bình để xác thực qua passkey so với mật khẩu (hoặc các phương pháp cũ khác), từ thời điểm người dùng bắt đầu đăng nhập cho đến khi hoàn thành thành công. | Việc đăng nhập bằng passkey nhanh hơn tương quan với sự hài lòng của người dùng cao hơn và việc sử dụng bền vững. | Ghi lại dấu thời gian bắt đầu và thành công của từng nỗ lực đăng nhập. Tính toán thời gian đăng nhập passkey trung bình so với thời gian đăng nhập cũ trung bình. Phân khúc theo Hệ điều hành/trình duyệt/thiết bị để có cái nhìn sâu sắc hơn. | Tốc độ tăng từ 3 đến 5 lần. Khi so sánh với MFA hiện có (Mật khẩu + SMS). |
| Tỷ lệ Dự phòng (Fallback Rate) | Tần suất người dùng quay lại sử dụng mật khẩu hoặc một phương pháp không phải passkey khác trong một nỗ lực đăng nhập ban đầu được bắt đầu bằng một passkey. | Cho thấy sự phụ thuộc liên tục vào các luồng cũ, có thể do độ tin cậy của passkey kém hoặc do người dùng cảm thấy không thoải mái. | Công thức: (Số sự kiện dùng phương án dự phòng) ÷ (Số lần thử đăng nhập bằng passkey) Tương quan dữ liệu phương án dự phòng với các cuộc khảo sát người dùng hoặc các phiếu hỗ trợ để xác định nguyên nhân gốc rễ. | KPI này về cơ bản là tỷ lệ đăng nhập passkey bị đảo ngược và phụ thuộc vào việc triển khai của bạn. |
Điều quan trọng là phải tối ưu hóa chủ yếu cho việc đăng nhập passkey thành công và tỷ lệ đăng nhập passkey để đảm bảo trải nghiệm người dùng không gặp rào cản, đồng thời làm việc để tăng tỷ lệ kích hoạt người dùng - nhưng chỉ khi tỷ lệ đăng nhập thành công đủ cao để tránh gây ra sự bực bội cho người dùng. Ngoài ra, việc theo dõi các KPI này theo các phân khúc khác nhau (chẳng hạn như Hệ điều hành, trình duyệt và thiết bị) và các trường hợp sử dụng cụ thể (ví dụ: đăng nhập trên nhiều thiết bị) có thể cung cấp những thông tin chi tiết hơn về các mô hình áp dụng và các điểm cản trở tiềm năng.
Việc đo lường chính xác cả các KPI đầu vào (ví dụ: sự chấp nhận, việc tạo) và KPI đầu ra (ví dụ: tỷ lệ đăng nhập, mức độ sử dụng phương án dự phòng) đòi hỏi phải thu thập dữ liệu từ ba nguồn chính:
Để tính toán các chỉ số như Tỷ lệ Chấp nhận Passkey hoặc Tỷ lệ Tạo Passkey Thành công, bạn phải phát hiện được có bao nhiêu người dùng nhìn thấy một gợi ý sau khi đăng nhập, có bao nhiêu người nhấp vào “Có, tạo một passkey” và liệu họ có thực sự hoàn thành việc tạo passkey hay không. Điều này yêu cầu tính năng theo dõi sự kiện bằng JavaScript (hoặc ứng dụng di động gốc) để ghi nhận:
Bạn cũng sẽ cần phân tích chuỗi user agent (user agent parsing) hoặc client hints để liên kết tỷ lệ chấp nhận với các phiên bản Hệ điều hành / trình duyệt cụ thể nhằm có thể phát hiện các đường dẫn bị hỏng cụ thể.
Sau khi người dùng bắt đầu quá trình đăng ký ở front-end, máy chủ phải xác nhận xem một passkey mới có thực sự được lưu trữ hay không. Bạn sẽ cần quyền truy cập vào cơ sở dữ liệu hoặc API của một nhà cung cấp định danh bên ngoài ghi lại sự kiện tạo của mỗi thông tin xác thực. Kho lưu trữ này giúp bạn đếm xem mỗi người dùng có bao nhiêu passkey và theo dõi kết quả cuối cùng (thành công hoặc thất bại), đảm bảo bạn biết chính xác những nỗ lực nào đã kết thúc bằng việc đăng ký hoàn tất.
Đối với các chỉ số như Tỷ lệ Dự phòng, bạn phải xem xét các quy trình & nhật ký xác thực hiện tại của mình. Bằng cách hợp nhất các nhật ký này với các sự kiện ở front-end, bạn xem liệu một người dùng có bắt đầu đăng nhập bằng passkey, bị lỗi và sau đó chuyển sang đăng nhập dự phòng (ví dụ: SMS hoặc mật khẩu) hay không.
Cuối cùng, việc đo lường các KPI dựa trên thời gian chẳng hạn như Thời gian Đăng nhập Passkey so với Thời gian Đăng nhập Cũ dựa vào dấu thời gian của cả máy khách và máy chủ. Bởi vì nhiều tổ chức chỉ ghi lại các lần đăng nhập thành công, bạn phải thêm các công cụ để theo dõi các luồng passkey thất bại hoặc bị hủy giữa chừng nhằm thực sự đánh giá được ma sát và sự phụ thuộc vào phương án dự phòng. Việc tích hợp ba nguồn dữ liệu này, đồng thời tôn trọng các ràng buộc về quyền riêng tư và quy định, thường phức tạp hơn dự đoán và là một yếu tố khác khiến một số nhóm áp dụng các nền tảng passkey chuyên dụng cung cấp các công cụ theo dõi sự kiện và phân tích được tích hợp sẵn.
Các thành phần của Corbado Connect thu thập một cách ngầm định tất cả các điểm dữ liệu được mô tả (hàng trăm điểm dữ liệu khác nhau) bằng cách tự động tạo ra một quy trình duy nhất cho mọi người dùng bắt đầu quy trình xác thực. Thông qua sự tích hợp liền mạch, Corbado cũng thu thập các chỉ số xác thực từ giải pháp hiện có của bạn. Chế độ xem toàn diện này chỉ ra chính xác các điểm cần cải thiện cho người dùng, cung cấp thông tin chi tiết toàn diện về tất cả các KPI cốt lõi của passkey mà không cần bất kỳ nỗ lực bổ sung nào từ phía bạn.
Ngoài ra, tác động của các KPI đầu ra sau đây cũng sẽ xuất hiện sau khi triển khai passkey thành công và phần lớn thời gian đã được thu thập trong doanh nghiệp:
Các Chỉ số Hoạt động & Giảm thiểu Chi phí
Các Chỉ số Kinh doanh & Tác động UX
Bằng cách theo dõi cụ thể các KPI đầu vào và đầu ra của passkey và liên kết chúng với các dữ liệu khác, các tổ chức có thể định lượng tác động của việc triển khai passkey và đưa ra những cải tiến dựa trên dữ liệu để tối đa hóa sự áp dụng, giảm chi phí và tăng cường bảo mật.
Việc lựa chọn giải pháp passkey phù hợp phụ thuộc vào những thách thức cụ thể, yêu cầu bảo mật và các cân nhắc về chi phí của bạn. Dưới đây là những khuyến nghị chính cho các quyết định mua hay tự xây dựng trên các lĩnh vực khác nhau.
Các Lưu ý Chính:
Khuyến nghị:
Hầu hết các ngân hàng và tổ chức tài chính nên dựa vào một giải pháp từ nhà cung cấp passkey thay vì tự xây dựng nội bộ, vì việc quản lý cơ sở hạ tầng passkey nội bộ mang lại những sự phức tạp tiềm ẩn vượt quá chuyên môn IT truyền thống. Việc triển khai xác thực bằng passkey ở quy mô lớn đòi hỏi sự tối ưu hóa và cập nhật liên tục, quản lý khả năng tương thích của WebAuthn và sự tích hợp liền mạch với các hệ thống ngân hàng cũ - tất cả những điều mà các nhà cung cấp passkey đã xử lý.
Các ngân hàng như Ubank, Revolut và Finom đang dẫn đầu trong việc áp dụng passkey, nhận ra tiềm năng của công nghệ này trong việc tăng cường bảo mật đồng thời cải thiện trải nghiệm người dùng. Việc phân tích ROI passkey thường nghiêng về hướng mua một giải pháp passkey hơn là đầu tư vào việc bảo trì và cập nhật liên tục, với việc triển khai cho thấy sự sụt giảm đáng kể trong các nỗ lực gian lận và chi phí hỗ trợ liên quan đến xác thực.
Các ví dụ: Armstrong Bank, First Financial Bank, Ubank, Revolut, Finom, Neobank, Cathay Financial Holdings, Stripe, PayPal, Square
Các Lưu ý Chính:
Khuyến nghị:
Một giải pháp từ nhà cung cấp passkey là cách hiệu quả nhất để đáp ứng các yêu cầu tuân thủ đồng thời đơn giản hóa việc xác thực. Các nhà cung cấp passkey xử lý các bản vá bảo mật, các bản cập nhật tuân thủ và độ tin cậy của việc xác thực, giảm bớt gánh nặng cho các nhóm IT.
Các ví dụ: CVS Health, Caremark, Helsana, NHS, Swica
Các Lưu ý Chính:
Khuyến nghị:
Các nền tảng thương mại điện tử được hưởng lợi nhiều nhất từ một nhà cung cấp triển khai passkey có tỷ lệ áp dụng cao. Các nền tảng lớn như Amazon và Shopify đã triển khai xác thực bằng passkey, chứng minh sự áp dụng ngày càng tăng của công nghệ này trong thương mại điện tử. Dữ liệu thực tế cho thấy hơn 27% các lần đăng nhập bằng mật khẩu ban đầu bị thất bại, trong khi xác thực dựa trên passkey có thể đạt tỷ lệ đăng nhập thành công lên đến 95-97% như đã được thấy ở các lần áp dụng trước đó. Phân tích ROI passkey cho thấy tỷ lệ chuyển đổi cao hơn và tổn thất do gian lận thấp hơn nhanh chóng biện minh cho khoản đầu tư này.
Amazon gần đây cho biết rằng họ đã đặt ra một mục tiêu đầy tham vọng là áp dụng passkey 100% và loại bỏ hoàn toàn mật khẩu.
Google cũng phát hiện ra rằng những người dùng dùng thử có tương tác với passkey có khả năng chuyển đổi thành khách hàng trả phí cao hơn 20% so với những người không sử dụng.
Các ví dụ: KAYAK, Amazon, Mercari, Best Buy, eBay, Home Depot, Shopify, Target
Các Lưu ý Chính:
Khuyến nghị:
Hầu hết các công ty du lịch nên triển khai các giải pháp passkey để nâng cao bảo mật và trải nghiệm người dùng. Các công ty hàng đầu như Kayak và các hãng hàng không lớn đã và đang sử dụng xác thực bằng passkey để cải thiện trải nghiệm người dùng của họ. Các giải pháp dựng sẵn cung cấp khả năng phát hiện gian lận mạnh mẽ hơn, trải nghiệm đăng nhập liền mạch và hỗ trợ đa thiết bị ngay tức thì. Lĩnh vực khách sạn đặc biệt được hưởng lợi từ việc giảm thời gian check-in và cải thiện bảo mật thông qua việc triển khai passkey, đảm bảo việc xác thực suôn sẻ trên tất cả các điểm tiếp xúc (ứng dụng, ki-ốt, web và các nền tảng đối tác).
Các ví dụ: Air New Zealand, Bolt, Grab, Uber, Hyatt
Các Lưu ý Chính:
Khuyến nghị:
Một giải pháp passkey bên ngoài là phù hợp nhất để triển khai nhanh chóng và tuân thủ các quy định. Các nhà cung cấp bảo hiểm báo cáo sự sụt giảm đáng kể đối với các phiếu hỗ trợ liên quan đến xác thực sau khi triển khai passkey. Một nhà cung cấp triển khai passkey với các luồng xác thực có thể tùy chỉnh và việc xác minh danh tính được tích hợp đảm bảo bảo mật trong khi vẫn giữ cho quá trình đăng nhập của khách hàng trở nên đơn giản. Phân tích ROI passkey cho thấy rằng việc giảm thiểu các lần đặt lại mật khẩu và tổn thất do gian lận bù đắp cho chi phí của nhà cung cấp.
Các ví dụ: Branch
Các Lưu ý Chính:
Khuyến nghị:
Đối với các cơ quan chính phủ, một giải pháp passkey chuyên biệt đáp ứng các tiêu chuẩn bảo mật nghiêm ngặt trong khi vẫn đảm bảo khả năng tiếp cận là điều thiết yếu. Thành công trong việc triển khai tại VicRoads chứng minh rằng các tổ chức chính phủ được hưởng lợi nhiều nhất từ các giải pháp passkey bên ngoài có thể xử lý các yêu cầu tuân thủ và cập nhật bảo mật một cách tự động. Do đó, hãy chọn một nhà cung cấp triển khai passkey cung cấp bảo mật cấp doanh nghiệp, hỗ trợ xác thực trên nhiều thiết bị và cung cấp các luồng xác thực thích ứng để tạo sự thuận tiện cho mọi công dân.
Ví dụ: VicRoads, myGov, State of Michigan
Các Lưu ý Chính:
Khuyến nghị:
Đối với các nhà cung cấp viễn thông và tiện ích, việc áp dụng một giải pháp passkey bên ngoài là phương pháp được khuyến nghị. Do quy mô, mức độ phức tạp và yêu cầu bảo mật của các ngành này, một nhà cung cấp passkey được quản lý đảm bảo tuân thủ, tính khả dụng cao và tích hợp liền mạch với cơ sở hạ tầng xác thực hiện có. Những người khổng lồ viễn thông và các nhà cung cấp tiện ích ưu tiên kỹ thuật số đang đón nhận passkey như là một phần trong nỗ lực hiện đại hóa bảo mật của họ để giảm gian lận và cải thiện trải nghiệm người dùng. Ngoài ra, việc thuê ngoài triển khai passkey làm giảm Tổng chi phí sở hữu (TCO) so với việc tự xây dựng nội bộ, vì việc bảo trì liên tục, các bản cập nhật bảo mật và việc tuân thủ quy định sẽ do nhà cung cấp đảm nhận.
Ví dụ: Deutsche Telekom, Telstra, SK Telecom
Các Lưu ý Chính:
Khuyến nghị:
Đối với hầu hết các nhà cung cấp B2B SaaS, việc triển khai passkey từ bên ngoài là lựa chọn tối ưu. Việc triển khai thường nhanh hơn so với tự phát triển nội bộ. Các công ty B2B kỹ thuật số như Notion, Hubspot hoặc Vercel đã áp dụng passkey để tăng cường bảo mật xác thực của họ. Tổng chi phí sở hữu thấp hơn đáng kể so với việc phát triển nội bộ, vì các yêu cầu về bảo trì, cập nhật và tuân thủ đều được đáp ứng bởi nhà cung cấp.
Ví dụ: Canva, DocuSign, Notion
Passkey đã trở thành tiêu chuẩn toàn cầu cho việc xác thực, đơn giản hóa các lần đăng nhập cho người dùng cuối đồng thời tăng cường bảo mật. Khi các công ty đánh giá cách triển khai passkey, họ phải quyết định xem nên xây dựng một giải pháp nội bộ hay tận dụng một nhà cung cấp passkey chuyên biệt. Mặc dù các triển khai tự làm cung cấp toàn quyền kiểm soát, nhưng chúng đòi hỏi chuyên môn kỹ thuật đáng kể, nguồn lực phát triển và bảo trì liên tục. Ngược lại, các nhà cung cấp passkey cung cấp một cách tiếp cận nhanh hơn, có thể mở rộng và hiệu quả về mặt chi phí, đảm bảo tỷ lệ áp dụng cao, trải nghiệm người dùng liền mạch và sự tuân thủ các tiêu chuẩn bảo mật đang phát triển,
Hướng dẫn này đã giải quyết các câu hỏi chính sau::
Cần những thành phần nào để triển khai passkey và chuyển sang không mật khẩu?
Việc triển khai passkey thành công đòi hỏi cơ sở hạ tầng FIDO2/WebAuthn, các luồng UX trơn tru, các cơ chế dự phòng và các tùy chọn khôi phục tài khoản an toàn. Các công ty cũng phải xem xét khả năng tương thích đa nền tảng và tuân thủ bảo mật.
Tôi có nên triển khai passkey nội bộ hay sử dụng một nhà cung cấp bên ngoài?
Mặc dù việc phát triển nội bộ cung cấp quyền kiểm soát, nhưng nó đi kèm với độ phức tạp cao, chi phí bảo trì liên tục và các trách nhiệm về bảo mật. Hầu hết các tổ chức đối mặt với người tiêu dùng quy mô lớn đều được hưởng lợi từ một giải pháp passkey bên ngoài cung cấp khả năng triển khai nhanh chóng, chi phí vận hành thấp hơn và giảm bớt gánh nặng kỹ thuật.
Lợi ích của việc có một nhà cung cấp passkey là gì khi có các thư viện mã nguồn mở?
Các thư viện WebAuthn mã nguồn mở cung cấp một điểm khởi đầu nhưng thiếu tính bảo mật cấp doanh nghiệp, trải nghiệm người dùng được tối ưu hóa cho passkey và các tính năng nâng cao khả năng áp dụng. Một nhà cung cấp passkey đảm bảo triển khai liền mạch, khả năng mở rộng và các chiến lược áp dụng của người dùng được tối ưu hóa mang lại ROI tốt hơn, làm giảm ma sát cho cả người dùng và nhà phát triển.
Những thách thức lớn nhất trong việc xây dựng một giải pháp passkey là gì?
Việc phát triển một hệ thống passkey nội bộ đòi hỏi chuyên môn sâu về WebAuthn, hỗ trợ đa thiết bị và áp dụng passkey. Việc duy trì sự phức tạp liên tục của thiết bị và trình duyệt cũng như đảm bảo tỷ lệ áp dụng cao càng làm tăng thêm độ khó.
Những rủi ro của việc triển khai passkey nội bộ là gì?
Các công ty đối mặt với rủi ro chi phí phát triển cao, thời gian triển khai kéo dài và gánh nặng bảo trì bảo mật liên tục. Những thất bại trong tuân thủ, lỗ hổng bảo mật và sự áp dụng kém của người dùng có thể làm hỏng sự thành công của một lần triển khai passkey. Một giải pháp passkey được nhà cung cấp quản lý sẽ giảm thiểu những rủi ro này bằng cách cung cấp một cơ sở hạ tầng xác thực đã được chứng minh, có thể mở rộng với tính năng bảo mật tích hợp và tuân thủ quy định.
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 →
Việc xây dựng nội bộ đòi hỏi chuyên môn sâu về WebAuthn, việc quản lý khả năng tương thích của trình duyệt và thiết bị liên tục, và sự bảo trì bảo mật chuyên dụng. Các công ty gặp rủi ro về thời gian triển khai bị kéo dài, những thất bại trong việc tuân thủ và sự áp dụng kém của người dùng. Đối với các ngành được quản lý chặt chẽ như ngân hàng và chăm sóc sức khỏe, việc tuân thủ các quy định như PSD2, HIPAA và NIST làm tăng thêm sự phức tạp mà các nhà cung cấp passkey đã xử lý liên tục.
Các tổ chức cần từ 50-80% người dùng hoạt động tiến hành xác thực bằng passkey trước khi gỡ bỏ mật khẩu. Việc loại bỏ mật khẩu quá sớm sẽ làm tăng các yêu cầu hỗ trợ và các vấn đề về khả năng sử dụng. Một cách tiếp cận theo từng giai đoạn bắt đầu với các tài khoản nơi người dùng thường xuyên xác thực qua passkey, tận dụng nhiều lần gợi ý (tỷ lệ chấp nhận đạt tới 85% trên thiết bị di động sau nhiều lời nhắc) và mở rộng dựa trên những thông tin chi tiết từ dữ liệu.
Theo dõi các KPI đầu vào bao gồm tỷ lệ chấp nhận passkey (mốc chuẩn: 50-75% ở lần gợi ý đầu tiên, lên đến 85% trên thiết bị di động qua nhiều lần gợi ý) và tỷ lệ tạo thành công hướng tới gần 100%. Đối với các KPI đầu ra, hãy nhắm mục tiêu tỷ lệ đăng nhập bằng passkey trên 20% trong vòng vài tuần và trên 50% trong 12 tháng. Phân khúc tất cả các chỉ số theo hệ điều hành, trình duyệt và thiết bị để xác định các điểm gây cản trở.
Hầu hết các dự án passkey thất bại do sự áp dụng của người dùng thấp chứ không phải do các vấn đề kỹ thuật. Việc người dùng tiếp tục phụ thuộc vào mật khẩu sẽ phủ nhận các lợi ích bảo mật, triệt tiêu sự tiết kiệm chi phí từ việc giảm thiểu SMS OTP và đặt lại mật khẩu, đồng thời tạo ra một trải nghiệm người dùng bị phân mảnh. Google và Amazon giải quyết vấn đề này thông qua các thử nghiệm A/B liên tục, các gợi ý trên giao diện người dùng và các chiến dịch giáo dục người dùng có cấu trúc nhằm đặc biệt vào việc thúc đẩy sự áp dụng.
Các lĩnh vực ngân hàng, chăm sóc sức khỏe, chính phủ, thương mại điện tử, viễn thông và bảo hiểm được hưởng lợi nhiều nhất từ các giải pháp của nhà cung cấp passkey do các yêu cầu về quy định như PSD2, HIPAA và NIST, kết hợp với các tập người dùng quy mô lớn và cơ sở hạ tầng cũ phức tạp. Amazon đã đặt ra mục tiêu áp dụng 100% passkey và loại bỏ hoàn toàn mật khẩu, minh họa cho quy mô cam kết mà các đợt triển khai này yêu cầu.
Bài viết liên quan
Mục lục