Hướng dẫn Mua hay Tự xây dựng giải pháp Passkey

Tải xuống miễn phí Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ và tiếp cận tất cả các thông tin chi tiết.

• ✅ Được các đội ngũ tại Adidas, Woolworths & Mitsubishi yêu cầu
• ✅ Danh sách đầy đủ các thành phần và mô hình chi phí để quyết định giữa mua và tự xây dựng
• ✅ Khung quyết định thực tế dài 50 trang

Ý tưởng tự xây dựng một hệ thống passkey nghe có vẻ hấp dẫn: toàn quyền kiểm soát, tích hợp tùy chỉnh và không bị phụ thuộc vào nhà cung cấp. Suy 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 có vẻ khá dễ dàng. Thực sự thì nó có thể khó đến mức nào?

Nhưng đây thường là lúc sự phức tạp bắt đầu, đặc biệt là khi chúng ta 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 người tiêu dùng với hàng triệu người dùng trong các ngành như:

• Ngân hàng & Dịch vụ tài chính (ví dụ: trực tuyến, ngân hàng, thanh toán, fintech)
• Chính phủ & Dịch vụ công (ví dụ: cổng thông tin công dân, nền tảng thuế & an sinh xã hội)
• Bảo hiểm & Chăm sóc sức khỏe (ví dụ: cổng thông tin bệnh nhân, nền tảng bảo hiểm kỹ thuật số)
• Thương mại điện tử & Bán lẻ (ví dụ: sàn giao dịch, chương trình khách hàng thân thiết)
• Viễn thông & Tiện ích (ví dụ: nhà mạng di động, nhà cung cấp năng lượng)
• Du lịch & Khách sạn (ví dụ: tài khoản hãng hàng không, chương trình khách hàng thân thiết của khách sạn)

Thách thức thực sự bắt đầu sau lần đăng nhập bằng passkey thành công đầu tiên và thường chỉ lộ ra khi chúng ta đã và đang trong quá trình 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 hiếm gặp, lỗi người dùng khó hiểu và nguy cơ người dùng bị khóa tài khoản do passkey không khả dụng xuất hiện. Việc tích hợp tưởng chừng đơn giản lại biến thành nỗ lực phát triển kéo dài hàng tháng, thậm chí hàng năm, chi phí bảo trì không lường trước và có khả năng dẫn đến một dự án passkey thất bại.

Tuy nhiên, tự xây dựng giải pháp cũng có thể là lựa chọn đúng đắn cho một số tổ chức và yêu cầu cụ thể. Chúng tôi đã trao đổi với hàng chục tổ chức về kế hoạch triển khai passkey của họ và đã trực tiếp đồng hành cùng một số tổ chức trên hành trình này. Hướng dẫn này sẽ giúp bạn xác định khi nào phương pháp tự làm (Do-It-Yourself - DIY) passkey có thể hợp lý và khi nào việc chọn một nhà cung cấp passkey uy tín 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:

1. Cần những thành phần nào để triển khai passkey và tiến tới không mật khẩu?
2. Nên tự triển khai passkey hay sử dụng một nhà cung cấp passkey bên ngoài?
3. Lợi ích của việc có một nhà cung cấp passkey khi đã có các thư viện mã nguồn mở là gì?
4. Những thách thức lớn nhất khi xây dựng một giải pháp passkey là gì?
5. Những rủi ro khi tự triển khai passkey là gì?

Mật khẩu đã lỗi thời, không an toàn và gây khó chịu. 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 việc xác thực - khiến chúng trở thành tiêu chuẩn mới cho việc đăng nhập an toàn. Dù bạn tự xây dựng hay sử dụng giải pháp bên ngoài, việc tích hợp passkey là một 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 nhấn mạnh vào câu chuyện về sự dễ sử dụng hoặc tốc độ sẽ tạo được tiếng vang và hiệu quả. Mọi người thường phàn nà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 điểm cộng lớn.

Ngoài những lợi ích bảo mật này, còn có tiềm năng to lớn trong việc tiết kiệm chi phí hoạt động với passkey. Chúng ta có thể giảm số lượng SMS OTP gửi cho người dùng, một khoản chi phí có thể tăng lên rất nhiều đối với lượng người dùng lớn. Hơn nữa, gánh nặng từ việc khôi phục mật khẩu và MFA đặt lên đội ngũ hỗ trợ khách hàng cũng là một yếu tố chi phí có thể được loại bỏ.

Bên cạnh đó, 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 trong 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 cân nhắc giới thiệu passkey là hoàn toàn không 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 năng lực 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 để giới thiệu phương thức xác thực an toàn hơn hoặc các hạn chế về tài chính cũng có thể đóng một vai trò.

Hãy cùng đi qua bốn giai đoạn này và mô tả chúng, vì việc triển khai passkey chỉ là một bước trong việc đảm bảo sự thành công của một dự án passkey.

Bước đầu tiên trong quá trình chuyển đổi sang hệ thống hoàn toàn không mật khẩu là tích hợp passkey như 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. Việc 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 và chính sách bảo mật hiện có. 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 có chuyên môn kỹ thuật và không có chuyên môn kỹ thuật đều có thể áp dụng phương thức xác thực mới mà không gặp trở ngại.

Khi passkey đã được tích hợp, thách thức tiếp theo là thúc đẩy người dùng chấp nhận 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ự chấp nhận rộng rãi của người dùng, một dự án passkey có khả năng 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 tỷ lệ chấp nhận bao gồm giáo dục người dùng một cách chủ động, các gợi ý trên giao diện người dùng (UI nudges) nhằm quảng bá việc tạo passkey và các chương trình khuyến khích (incentive) thưởng cho người dùng khi chuyển đổi. Các tổ chức nên đặt ra một ngưỡng chấp nhận quan trọng, chẳng hạn như 50-80% người dùng đang 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 việc chấp nhận 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ề việc tỷ lệ chấp nhận thấp có thể gây nguy hiểm cho dự án passkey của bạn như thế nào.

Khi tỷ lệ chấp nhận 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à tăng yêu cầu hỗ trợ. Một phương pháp tiếp cận theo từng giai đoạn được khuyến nghị:

• Bắt đầu bằng cách loại bỏ mật khẩu khỏi các tài khoản mà người dùng thường xuyên xác thực bằng passkey.
• Cung cấp tùy chọn loại bỏ mật khẩu trong cài đặt tài khoản cho những người dùng sớm.
• Sử dụng thông tin chi tiết dựa trên dữ liệu để xác định những người dùng đã sẵn sàng chuyển sang hoàn toàn không dùng mật khẩu. Ví dụ, những người dùng có nhiều passkey được đăng ký trên các thiết bị khác nhau có thể được ưu tiên loại bỏ mật khẩu.
• Chủ động truyền đạt những lợi ích của việc loại bỏ mật khẩu để xây dựng lòng tin của người dùng.

Bằng cách hướng dẫn người dùng một cách chiến lược hướng tới việc xác thực không mật khẩu hoàn toàn, 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.

Khi mật khẩu được loại bỏ, các cơ chế khôi phục tài khoản phải 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 sự can thiệp thủ công, chẳng hạn như phiếu hỗ trợ hoặc đặt lại qua email, điều này 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 nhằm duy trì bảo mật trong khi 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:

• Kiểm tra sự sống (Liveness checks): Ngăn chặn việc chiếm đoạt tài khoản trái phép bằng cách đảm bảo người dùng có mặt thực tế.
• Xác minh danh tính (ID verification): Tận dụng giấy tờ tùy thân do chính phủ cấp và xác minh sinh trắc học để xác nhận danh tính.
• Passkey dự phòng: Cho phép người dùng khôi phục tài khoản bằng cách sử dụng các passkey dự phòng được lưu trữ trên các thiết bị khác của họ.

Nhiều tổ chức đã đầ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 sự phiền toái.

Dựa trên bốn giai đoạn này, bây giờ 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 khi đó bạn sẽ bỏ lỡ toàn bộ tiềm năng của passkey).

Việc lựa chọn giữa giải pháp passkey tự làm và giải pháp 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 đây cho thấy các tiêu chí đánh giá khác nhau mà bạn cần xem xét. Dựa trên phát biểu mà bạn nghiêng về nhiều hơn, 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.

• Gán 1 điểm cho mỗi câu trả lời mà độ phức tạp trong trường hợp của bạn là thấp nhất và phù hợp hơn với mô tả bên trái.
• Gán 5 điểm cho mỗi hạng mục mà câu trả lời của bạn phù hợp hơn với mô tả có độ phức tạp cao nhất bên phải.
• Nếu bạn không chắc chắn, hãy sử dụng 3 điểm làm tùy chọn trung lập.

Tải xuống miễn phí Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ và tiếp cận tất cả các tiêu chí đánh giá.

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, chứ 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 ngắn hạn của bạn là cung cấp passkey như một MVP (sản phẩm khả dụng tối thiểu), bạn nên lường trước những hệ quả lâu dài, đặc biệt là thúc đẩy việc chấp nhận. 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 mình, với sự nhấn mạnh vào lý do tại sao việc chấp nhận lại quan trọng hơn hầu hết mọi yếu tố khác.

Bất kể giải pháp passkey của bạn tiên tiến đến đâu, nếu người dùng không chấp nhận 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 để 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, tỷ lệ chấp nhận thấp sẽ dẫn đến:

• Sự phụ thuộc dai dẳng vào mật khẩu, làm mất đi lợi ích bảo mật của passkey.
• ROI tối thiểu, vì việc tiết kiệm chi phí (ít lần đặt lại mật khẩu hơn, giảm SMS OTP) phụ thuộc vào việc sử dụng passkey đáng kể để đăng nhập.
• Trải nghiệm người dùng bị phân mảnh, nếu hầu hết các lần đăng nhập vẫn diễn ra qua các phương thức truyền thống và chỉ một nhóm nhỏ sử dụng passkey.

Tỷ lệ chấp nhận 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ể 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 chấp nhận rõ ràng và chạy thử nghiệm A/B một cách có hệ thống, các 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 để đảm bảo passkey được đón nhận rộng rãi. Nỗ lực tập trung vào việc chấp nhận này 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 hữu hình.

Hướng dẫn này được thiết kế để giúp bạn đưa ra 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:

1. Giai đoạn 1 (Tích hợp Passkey): Nếu bạn chỉ đơn giản là đang xem xét có nên áp dụng passkey hay không và cách tích hợp chúng, hãy tập trung vào các tiêu chí Xây dựng so với Mua cho việc tích hợp passkey.
2. Giai đoạn 2 (Tăng tỷ lệ chấp nhận): Nếu bạn muốn passkey không chỉ là một tính năng, hãy lên kế hoạch sớm để thúc đẩy người dùng chấp nhận - ngay cả đối với một MVP vì nó đòi hỏi đầu tư công nghệ bổ sung thường lớn hơn đáng kể so với việc triển khai ban đầu.
3. Giai đoạn 3 (Loại bỏ Mật khẩu): Nếu việc loại bỏ mật khẩu là một mục tiêu chiến lược dài hạn, hãy đảm bảo kiến trúc và luồng người dùng của bạn được thiết kế với bước đi cuối cùng đó trong tâm trí.
4. Giai đoạn 4 (Tự động hóa Khôi phục Tài khoản): Ngay cả khi bạn chưa sẵn sàng để hoàn toàn không dùng mật khẩu hôm nay, hãy chắc chắn rằng phương pháp tiếp cận passkey của bạn có thể phát triển thành việc khôi phục mạnh mẽ, liền mạch để tránh những trở ngại trong tương lai.

Trong số này, Giai đoạn 2 (Tăng tỷ lệ chấp nhận) là quan trọng nhất. Bạn có thể đánh giá từng phần riêng biệt, nhưng hãy nhớ rằng thành công và ROI lâu dài của bạn thường phụ thuộc vào việc bạn xem xét việc chấp nhận một cách nghiêm túc như thế nào 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 nó cùng với ban quản lý, IT, chủ sở hữu sản phẩm và các nhà ra quyết định quan trọng khác. Hãy tự hỏi mình:

1. Tỷ lệ đăng nhập bằng passkey mong muốn của chúng ta là gì? 5% có đủ để chứng minh tính khả thi hay chúng ta cần 50–80% trước khi coi passkey là một thành công?
2. Chúng ta có ngân sách và sự ủng hộ của ban điều hành để chạy thử nghiệm A/B trong nhiều tháng, chạy các chiến dịch tối ưu hóa, tạo tài liệu giáo dục và liên tục tinh chỉnh luồng người dùng để người dùng hiểu và muốn chuyển sang passkey không? Có đủ năng lực kỹ thuật để triển khai tất cả các báo cáo, phân tích và thử nghiệm cần thiết không? Chúng ta có thể phát hành đủ thường xuyên để đạt được những mục tiêu đó không?
3. Tầm nhìn dài hạn là gì? Chúng ta đang nhắm đến việc loại bỏ mật khẩu hay chỉ cung cấp một giải pháp thay thế?

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ên kế hoạch cho việc chấp nhận 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 suốt ma trận, mỗi tiêu chí đánh giá có thể đưa bạn đến bất cứ đâu từ độ phức tạp thấp nhất (1) đến độ phức tạp cao nhất (5). Càng nhiều câu trả lời của bạn chuyển đến và vượt ra ngoài vùng trung lập (3), trường hợp sử dụng một nhà cung cấp passkey chuyên biệt càng trở nên mạnh mẽ hơn:

• Yêu cầu có độ phức tạp cao - chẳng hạn như các phương pháp dự phòng nâng cao, tuân thủ nghiêm ngặt, phân tích sâu và UX đa thiết bị - nhân lên gánh nặng kỹ thuật và bảo trì của bạn.
• Nhấn mạnh vào việc chấp nhận - đạt được tỷ lệ chấp nhận passkey cao một cách nhanh chóng hoặc loại bỏ mật khẩu thường đòi hỏi các luồng người dùng đã được kiểm tra kỹ lưỡng, đo lường chi tiết và các gợi ý có cấu trúc.

Những yếu tố này có thể làm quá tải các đội ngũ nội bộ, cả về mặt kỹ thuật và 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ập nhật nhanh chóng và chuyên môn thực tế để tăng tốc độ chấp nhận nhanh hơn nhiều so với phương pháp tự làm.

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 trong lộ trình của bạn và bạn muốn một triển khai hiện đại nhất mà tích cực thúc đẩy việc chấp nhận, Corbado Connect có thể giúp bạn giải quyết các phức tạp ở quy mô lớn. Đây là lý do tại sao:

Việc chấp nhận được tích hợp sẵn trong 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ự lựa chọn 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 giúp tiết kiệm chi phí.

Các bước tiếp theo:

1. Điền vào từng phần liên quan của ma trận đánh giá - xem xét cả mục tiêu trước mắt và lâu dài.
2. Ưu tiên việc chấp nhận trong quá trình ra quyết định của bạn - thống nhất với các bên liên quan về các mục tiêu chấp nhận rõ ràng và nguồn lực để đạt được chúng.
3. So sánh TCO cho các giải pháp nội bộ và nhà cung cấp một khi bạn hiểu được độ phức tạp và tham vọng chấp nhận của mình và đi qua quy trình nội bộ để đánh giá xây dựng hay mua.

4. Tham khảo ý kiến các chuyên gia passkey (như Corbado) nếu các mục tiêu chiến lược của bạn hướng tới một nền tảng được quản lý hoàn toàn, xử lý hiệu quả cả thách thức kỹ thuật và thách thức về việc chấp nhận.

Bằng cách tiếp cận passkey một cách toàn diện và biến việc chấp nhận 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 hơn, đăng nhập đơn giản hơn và một con đường thực sự đến một 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 tỷ lệ chấp nhận passkey cao, chúng tôi luôn sẵn sàng trao đổi.

Bây giờ chúng ta đã giúp xác định phương pháp tiếp cận phù hợp để trả lời câu hỏi “Mua hay Tự xây dựng?”, chúng ta sẽ phân tích cách đánh giá sự thành công của một đợt triển khai passkey. Do đó, chúng ta xác định các chỉ số KPI đầu vào và đầu ra của một dự án passkey.

Các chỉ số KPI đầu vào giúp theo dõi việc chấp nhận passkey ở giai đoạn đầu và 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 đi trước hành vi đăng nhập thực tế nhưng rất quan trọng để cho phép việc chấp nhận có ý nghĩa và tối ưu hóa việc triển khai.

Những chỉ số KPI đầu vào này đóng vai trò là chỉ số hàng đầu về việc chấp nhận 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, luồng UX và triển khai kỹ thuật.

Các chỉ số KPI đầu ra (OKR) đo lường sự thành công thực tế của việc chấp nhận passkey bằng cách đánh giá hành vi của người dùng, các cải tiến hoạt động và tác động kinh doanh. Những chỉ số này phản ánh hiệu quả thực tế của một đợt triển khai passkey. Tỷ lệ Đăng nhập bằng Passkey là một KPI đầu ra cốt lõi vì nó trực tiếp phản ánh việc chấp nhận và sử dụng passkey thực tế. Một tỷ lệ đăng nhập bằng passkey tăng cho thấy việc 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ũ.

Điều quan trọng là phải tối ưu hóa chủ yếu cho sự thành công của việc đăng nhập bằng passkey và tỷ lệ đăng nhập bằng passkey để đảm bảo trải nghiệm người dùng không gặp trở ngại, đồng thời nỗ lự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ự thất vọng 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 (như HĐH, 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 thông tin chi tiết sâu hơn về các mô hình chấp nhận và các điểm có thể gây trở ngại.

Để đo lường chính xác cả KPI đầu vào (ví dụ: chấp nhận, tạo) và KPI đầu ra (ví dụ: tỷ lệ đăng nhập, sử dụng dự phòng) đòi hỏi việc thu thập dữ liệu từ ba nguồn chính:

1. Dữ liệu sự kiện từ Frontend
2. Kho lưu trữ Passkey / thông tin xác thực
3. Nhật ký xác thực truyền thống & dự phòng

Để 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ó bao nhiêu người dùng thấy một gợi ý sau khi đăng nhập, 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 đòi hỏi việc theo dõi sự kiện bằng JavaScript (hoặc di động gốc) để ghi lại:

• Khi nào và liệu gợi ý có được hiển thị hay không (lần đầu tiên so với các lần tiếp theo)
• Họ mất bao lâu để hoàn thành gợi ý
• Liệu họ có hủy bỏ quy trình tạo passkey một lần hay nhiều lần

Bạn cũng sẽ cần phân tích user agent hoặc client hints để liên kết tỷ lệ chấp nhận với các phiên bản HĐH / trình duyệt cụ thể để có thể phát hiện các đường dẫn bị lỗi cụ thể.

Sau khi người dùng bắt đầu đăng ký trên frontend, 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ận dạng 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 có bao nhiêu passkey tồn tại cho mỗi người dùng và theo dõi kết quả cuối cùng (thành công hay thất bại), đảm bảo bạn biết chính xác những lần thử 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 nhật ký & quy trình 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 frontend, bạn sẽ thấy liệu một người dùng đã bắt đầu đăng nhập bằng passkey, gặp lỗi và chuyển sang đăng nhập dự phòng (ví dụ: SMS hoặc mật khẩu).

Cuối cùng, việc đo lường các KPI dựa trên thời gian như Thời gian đăng nhập bằng Passkey so với Thời gian đăng nhập truyền thống phụ thuộc vào cả dấu thời gian của máy khách và máy chủ. 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ông cụ đo lường cho các luồng passkey không thành công hoặc một phần để thực sự đánh giá được sự phiền toái và việc sử dụng dự phòng. Việc tích hợp ba nguồn dữ liệu này, trong khi 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ự kiến và là một yếu tố khác khiến một số đội ngũ áp dụng các nền tảng passkey chuyên biệt cung cấp các phân tích và theo dõi sự kiện tích hợp sẵn.

Các thành phần của Corbado Connect ngầm thu thập tất cả các điểm dữ liệu được mô tả (hàng trăm điểm 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 một quy trình xác thực. Thông qua việc 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 tại của bạn. Cái nhìn toàn diện này xác định chính xác các cải tiế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 passkey thiết yếu mà không cần thêm nỗ lực từ phía bạn.

Ngoài ra, các hiệu ứng KPI đầu ra sau đây cũng sẽ xuất hiện sau một đợt triển khai passkey thành công và hầu hết thời gian đã được thu thập trong doanh nghiệp:

Các chỉ số về Hoạt động & Giảm chi phí

• Giảm việc sử dụng SMS OTP – Số lượng SMS OTP được tiết kiệm nhờ xác thực bằng passkey (tiết kiệm chi phí trực tiếp).
• Giảm yêu cầu đặt lại mật khẩu – Giảm các tương tác với bộ phận trợ giúp liên quan đến việc quên mật khẩu.
• Giảm số lượng phiếu hỗ trợ khách hàng – Giảm khối lượng các vấn đề dịch vụ khách hàng liên quan đến xác thực.
• Giảm khối lượng cuộc gọi hỗ trợ – Ít cuộc gọi đến liên quan đến các vấn đề truy cập tài khoản.

Các chỉ số về Tác động Kinh doanh & UX

• Tỷ lệ giữ chân người dùng – Tỷ lệ phần trăm người dùng tiếp tục xác thực sau lần đăng nhập đầu tiên.
• Tỷ lệ chuyển đổi – Tần suất người dùng hoàn thành giao dịch sau khi xác thực.
• Tỷ lệ bỏ ngang trong phễu đăng nhập – Liệu passkey có làm giảm số lượng người dùng bỏ ngang các lần thử đăng nhập.

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 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 của họ và thực hiện các cải tiến dựa trên dữ liệu để tối đa hóa việc chấp nhận, giảm chi phí và tăng cường bảo mật.

Việc 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ân nhắc về chi phí của bạn. Dưới đây là các khuyến nghị chính cho quyết định mua so với tự xây dựng trên các lĩnh vực khác nhau.

Những cân nhắc chính:

• Tuân thủ quy định (ví dụ: PSD2, SOC 2, ISO 27001, GDPR) đòi hỏi các biện pháp bảo mật nghiêm ngặt trong xác thực bằng passkey.
• So sánh chi phí passkey là rất quan trọng, vì các ngân hàng thường đánh giá thấp sự phức tạp và bảo trì lâu dài của các giải pháp nội bộ.
• Xác thực an toàn là cần thiết để giảm gian lận chiếm đoạt tài khoản và lừa đảo (phishing)

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, vì việc quản lý cơ sở hạ tầng passkey nội bộ gây ra những phức tạp ẩn giấu 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ý tương thích WebAuthn và 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 này 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. Phân tích ROI của passkey thường ủng hộ việc 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 các triển khai cho thấy sự giảm đáng kể các nỗ lực gian lận và chi phí hỗ trợ liên quan đến xác thực.

Ví dụ: Armstrong Bank, First Financial Bank, Ubank, Revolut, Finom, Neobank, Cathay Financial Holdings, Stripe, PayPal, Square

Những cân nhắc chính:

• Tuân thủ HIPAA và GDPR đòi hỏi bảo mật xác thực nghiêm ngặt trong việc áp dụng passkey.
• Những thách thức khi triển khai passkey bao gồm việc cân bằng giữa bảo mật và dễ sử dụng cho bệnh nhân, nhân viên y tế và quản trị viên IT của bệnh viện.
• Nhiều hệ thống xác thực trong chăm sóc sức khỏe vẫn dựa vào cơ sở hạ tầng cũ, làm cho việc tích hợp passkey trở nên phức tạp hơn.

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ủ trong khi đơ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ập nhật tuân thủ và độ tin cậy của xác thực, giảm bớt gánh nặng cho các đội ngũ IT.

Ví dụ: CVS Health, Caremark, Helsana, NHS, Swica

Những cân nhắc chính:

• Tối ưu hóa Tỷ lệ chuyển đổi (CRO) là yếu tố sống còn của doanh nghiệp - sự phiền toái trong xác thực ảnh hưởng trực tiếp đến doanh thu.
• Các kịch bản đa thiết bị phải hoạt động liền mạch (người dùng duyệt trên di động nhưng hoàn tất thanh toán trên máy tính để bàn).
• Lỗi xác thực trực tiếp làm tăng tỷ lệ bỏ giỏ hàng, khiến các luồng đăng nhập được tối ưu hóa UX trở nên cần thiết.

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 mang lại tỷ lệ chấp nhận 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 tỏ sự chấp nhận 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 thất bại, trong khi xác thực dựa trên passkey có thể đạt được tỷ lệ đăng nhập thành công lên đến 95-97% như đã thấy tại các lần áp dụng trước đây. Phân tích ROI của 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ư.

Amazon gần đây cho biết họ đã đặt mục tiêu tham vọng là 100% chấp nhận passkey 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 thử nghiệm 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 dùng.

Ví dụ: KAYAK, Amazon, Mercari, Best Buy, eBay, Home Depot, Shopify, Target

Những cân nhắc chính:

• Xác thực trên nhiều thiết bị là cần thiết, vì người dùng đặt chuyến đi trên một thiết bị và làm thủ tục trên một thiết bị khác.
• Các nhà cung cấp chuyên về passkey phải đảm bảo đăng nhập nhanh chóng và an toàn để đặt chỗ, làm thủ tục và quản lý tài khoản thuận tiện.
• Phòng chống gian lận là ưu tiên hàng đầu, vì các nền tảng du lịch xử lý các giao dịch có giá trị cao.

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 để tăng cường 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 đã 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ị tức thì. Ngành khách sạn đặc biệt được hưởng lợi từ việc giảm thời gian làm thủ tục và cải thiện bảo mật thông qua việc triển khai passkey, đảm bảo xác thực suôn sẻ trên tất cả các điểm tiếp xúc (ứng dụng, kiosk, web, và các nền tảng đối tác).

Ví dụ: Air New Zealand, Bolt, Grab, Uber, Hyatt

Những cân nhắc chính:

• Chi phí triển khai passkey phải phù hợp với nhu cầu tuân thủ và cải thiện trải nghiệm người dùng.
• Nhiều khách hàng bảo hiểm không rành về công nghệ, vì vậy trải nghiệm người dùng trên tất cả các loại thiết bị và trình duyệt là điều bắt buộc
• Tích hợp passkey với xác minh danh tính thường được yêu cầu để quản lý hợp đồng và xử lý yêu cầu bồi thường.

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ủ quy định. Các nhà cung cấp bảo hiểm báo cáo giảm đáng kể số lượng 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à xác minh danh tính tích hợp đảm bảo bảo mật trong khi vẫn giữ cho việc đăng nhập của khách hàng đơn giản. Phân tích ROI của passkey gợi ý rằng việc giảm đặt lại mật khẩu và tổn thất do gian lận sẽ bù đắp chi phí của nhà cung cấp.

Ví dụ: Branch

Những cân nhắc chính:

• Tiêu chuẩn bảo mật và yêu cầu tuân thủ cao nhất (ví dụ: NIST, khung Essential Eight yêu cầu MFA chống lừa đảo).
• Nhu cầu triển khai quy mô lớn trên các nhóm dân cư đa dạng với trình độ kỹ thuật khác nhau
• Yêu cầu tích hợp với các hệ thống xác minh danh tính của chính phủ hiện có và cơ sở hạ tầng cũ

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 đảm bảo khả năng tiếp cận là điều cần thiết. Sự thành công trong việc triển khai tại VicRoads cho thấy các tổ chức chính phủ hưởng lợi nhiều nhất từ các giải pháp passkey bên ngoài 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 đa thiết bị và cung cấp các luồng xác thực thích ứng để phù hợp với tất cả công dân.

Ví dụ: VicRoads, myGov, State of Michigan

Những cân nhắc chính:

• Khả năng mở rộng và độ tin cậy là rất quan trọng, vì các nhà cung cấp viễn thông và tiện ích thường quản lý hàng triệu người dùng trên các phân khúc khách hàng khác nhau, đòi hỏi xác thực có tính sẵn sàng cao và chịu lỗi tốt.
• Hỗ trợ đa thiết bị và đa nền tảng là cần thiết, vì người dùng truy cập tài khoản qua ứng dụng di động hoặc cổng thông tin web. Xác thực bằng passkey liền mạch phải hoạt động trên tất cả các điểm tiếp xúc của khách hàng.
• Hỗ trợ cho các hệ thống xác thực cũ thường là cần thiết, vì các nhà cung cấp viễn thông và tiện ích có thể cần tích hợp passkey vào các hệ thống IAM và nền tảng nhận dạng khách hàng hiện có mà không làm gián đoạn các luồng xác thực hiện tại.
• Phòng chống gian lận và bảo mật tài khoản là ưu tiên hàng đầu, đặc biệt là đối với gian lận hoán đổi SIM, trộm cắp danh tính và truy cập tài khoản trái phép. Passkey có thể giảm đáng kể các cuộc tấn công lừa đảo (phishing) và rủi ro nhồi thông tin xác thực (credential stuffing).

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ị. Với quy mô, độ phức tạp và yêu cầu bảo mật của những ngành này, một nhà cung cấp passkey được quản lý sẽ đảm bảo tuân thủ, tính sẵn sà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ó. Các gã khổng lồ viễn thông và các nhà cung cấp tiện ích ưu tiên kỹ thuật số đã và đang đón nhận passkey như một phần của 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, vì việc bảo trì liên tục, cập nhật bảo mật và các yêu cầu tuân thủ quy định đều do nhà cung cấp xử lý.

Ví dụ: Deutsche Telekom, Telstra, SK Telecom

Những cân nhắc chính:

• Xác thực đa người thuê (multi-tenant) là cần thiết cho B2B SaaS, đòi hỏi tích hợp passkey có thể mở rộng trên các hệ thống IAM khác nhau.
• Các doanh nghiệp mong đợi SSO (OIDC/SAML), do đó việc tích hợp liền mạch với các Nhà cung cấp danh tính là yếu tố sống còn của doanh nghiệp.
• Chi phí triển khai passkey phải được cân bằng với các khoản đầu tư bảo mật khác, chẳng hạn như xác thực đa yếu tố (MFA) và các mô hình bảo mật zero-trust.

Khuyến nghị: Đối với hầu hết các nhà cung cấp B2B SaaS, một giải pháp triển khai passkey 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 phát triển nội bộ. Các công ty B2B kỹ thuật số như Notion, Hubspot hoặc Vercel đã đón nhận 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 phát triển nội bộ, vì việc bảo trì, cập nhật và các yêu cầu tuân thủ đều được nhà cung cấp chi trả.

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 việc đăng nhập cho người dùng cuối trong khi 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 liệu 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. Trong khi các triển khai tự làm (DIY) cung cấp toàn quyền kiểm soát, 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 phương pháp tiếp cận nhanh hơn, có thể mở rộng và hiệu quả về chi phí, đảm bảo tỷ lệ chấp nhận cao, trải nghiệm người dùng liền mạch và 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à tiến tới không mật khẩu?

  Một đợt triển khai passkey thành công đòi hỏi cơ sở hạ tầng FIDO2/WebAuthn, các luồng UX liền mạch, 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.

• Nên tự triển khai passkey hay sử dụng một nhà cung cấp bên ngoài?

  Trong khi phát triển nội bộ cung cấp quyền kiểm soát, nó đi kèm với độ phức tạp cao, chi phí bảo trì liên tục và trách nhiệm bảo mật. Hầu hết các tổ chức quy mô lớn hướng đến người tiêu dùng đều hưởng lợi từ một giải pháp passkey bên ngoài cung cấp việc triển khai nhanh chóng, chi phí hoạt động thấp hơn và giảm gánh nặng kỹ thuật.

• Lợi ích của việc có một nhà cung cấp passkey khi đã có các thư viện mã nguồn mở là gì?

  Các thư viện WebAuthn mã nguồn mở cung cấp một điểm khởi đầu nhưng thiếu 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 tăng cường việc chấp nhận. Một nhà cung cấp passkey đảm bảo việc triển khai liền mạch, khả năng mở rộng và các chiến lược chấp nhận người dùng được tối ưu hóa mang lại ROI tốt hơn, giảm thiểu sự phiền toái cho cả người dùng và nhà phát triển.

• Những thách thức lớn nhất khi 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à việc chấp nhận passkey. Việc duy trì sự phức tạp liên tục của thiết bị và trình duyệt và đảm bảo tỷ lệ chấp nhận cao càng làm tăng thêm sự phức tạp.

• Những rủi ro khi tự triển khai passkey là gì?

  Các công ty có nguy cơ chịu 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. Thất bại trong việc tuân thủ, các lỗ hổng bảo mật và việc người dùng chấp nhận kém có thể làm hỏng thành công của một đợt triển khai passkey. Một giải pháp passkey do 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 bảo mật và tuân thủ quy định tích hợp sẵn.