Tại sao bạn cần Khả năng quan sát xác thực cho CIAM

1. Giới thiệu#

FIDO Alliance báo cáo tỷ lệ thành công của passkey là 93% - nhưng hầu hết các nhóm CIAM đều thấy tỷ lệ áp dụng bị kẹt ở mức từ 5% đến 15% sau khi ra mắt. Khoảng cách này tồn tại vì nhật ký backend không thể thấy những gì xảy ra trên thiết bị của người tiêu dùng. Khả năng quan sát xác thực thu hẹp khoảng cách đó.

2. Khả năng quan sát CIAM khác với IAM cho Lực lượng lao động như thế nào#

Nhận dạng người tiêu dùng và IAM cho lực lượng lao động dùng chung từ vựng nhưng ít có điểm chung. Trong IAM cho lực lượng lao động, bộ phận CNTT quản lý mọi máy tính xách tay, trình duyệt và khóa bảo mật. Nếu passkey bị hỏng, môi trường đã được biết trước. Trong CIAM, người tiêu dùng sử dụng các thiết bị không được quản lý - điện thoại Android giá rẻ, iPad năm năm tuổi, PC dùng chung có nhiều tiện ích mở rộng của trình quản lý mật khẩu - và môi trường phía máy khách không thể đoán trước được.

2.1 Người dùng Ẩn danh và Vấn đề Mù Thông tin Trước định danh#

Trong IAM cho lực lượng lao động, mọi người dùng đều tồn tại trong Active Directory trước khi họ đăng nhập. Trong CIAM, một người tiêu dùng hoàn toàn vô hình cho đến khi họ nhập email. Nếu họ rời đi trước thời điểm đó - vì lời nhắc passkey làm họ bối rối hoặc lớp phủ của trình quản lý mật khẩu chặn tính năng tự động điền - backend của bạn không ghi nhận được gì. "Sự mù lòa trước định danh" này là lỗ hổng tầm nhìn lớn nhất trong xác thực người tiêu dùng và là điểm thất thoát doanh thu nhiều nhất.

Ví dụ: Một nền tảng thương mại điện tử có tỷ lệ thoát 15% trên trang đăng nhập của họ nhưng không có lỗi backend nào. Khả năng quan sát phía máy khách tiết lộ rằng tiện ích mở rộng 1Password đang che khuất phần tự động điền passkey gốc. Người tiêu dùng thấy một giao diện lộn xộn và đã rời đi. Không có nhật ký máy chủ nào ghi lại được điều này.

2.2 Những Chỉ số nào quan trọng cho Xác thực Người tiêu dùng#

Khả năng quan sát xác thực cho CIAM điều chỉnh "các tín hiệu vàng" SRE cổ điển thành các KPI cụ thể cho đăng nhập. Những chỉ số quan trọng nhất cần theo dõi trong bảng điều khiển phân tích passkey:

• Tỷ lệ Đăng nhập Thành công (LSR): phần trăm nỗ lực đăng nhập hoàn tất mà không có lỗi. Nếu con số này giảm từ 91% xuống 85% chỉ sau một đêm, chắc chắn có thứ gì đó đã hỏng.
• Tỷ lệ Bỏ dở Xác thực: phần trăm người tiêu dùng bắt đầu luồng đăng nhập nhưng không bao giờ hoàn thành. Được theo dõi trên mọi điểm quyết định - từ khi truy cập trang đến khi hoàn tất xác minh sinh trắc học.
• Tỷ lệ Kích hoạt Passkey (Tỷ lệ Bổ sung): trong số tất cả người tiêu dùng có thiết bị hỗ trợ passkey, có bao nhiêu người đã tạo một khóa khi được yêu cầu? Mục tiêu: trên 60% người dùng đủ điều kiện trong năm đầu tiên.
• Tỷ lệ Sử dụng Passkey (Tỷ lệ Đăng nhập): trong số tất cả các lần đăng nhập, có bao nhiêu lần sử dụng passkey? Mục tiêu: trên 40% số lần đăng nhập. Được theo dõi dựa trên tỷ lệ dự phòng kế thừa để đo lường tiến độ áp dụng thực tế.
• Khối lượng Đặt lại Mật khẩu: sự gia tăng đột biến có nghĩa là người tiêu dùng không thể truy cập - một chỉ báo hàng đầu mạnh mẽ về tình trạng khách hàng rời bỏ và chi phí hỗ trợ ngày càng tăng.

Trong IAM cho lực lượng lao động, một lần đăng nhập không thành công sẽ tạo ra một vé hỗ trợ. Trong CIAM, nó tạo ra sự rời bỏ và chỉ có khả năng tạo ra một vé hỗ trợ. Xác thực kiểm soát mọi hành động có giá trị cao của người tiêu dùng - thanh toán, gia hạn đăng ký, truy cập bảng điều khiển. Một công ty SaaS đăng ký phát hiện ra rằng những người tiêu dùng có từ hai lần đăng nhập không thành công trở lên mỗi tháng rời bỏ ở mức gấp 3 lần tỷ lệ bình thường. Khả năng quan sát đã làm cho mối liên hệ đó trở nên rõ ràng.

3. Tại sao Nhật ký Backend và Phân tích chung thất bại đối với Passkey#

Hầu hết các nhóm CIAM dựa vào nhật ký IdP và các công cụ như GA4 hoặc Mixpanel. Đối với đăng nhập bằng mật khẩu, điều đó là đủ. Đối với passkey, thì không - vì khoảnh khắc quan trọng đã chuyển từ máy chủ sang thiết bị của người tiêu dùng.

3.1 "Hộp Đen" Phía máy khách#

Với mật khẩu, luồng thông tin rất đơn giản: người tiêu dùng gửi thông tin xác thực, máy chủ kiểm tra chúng, máy chủ ghi lại kết quả. Với passkey, trình duyệt sẽ mở một cửa sổ hệ điều hành gốc - iCloud Keychain, Google Password Manager, Windows Hello hoặc một tiện ích mở rộng của bên thứ ba. Nếu sinh trắc học hết thời gian chờ, trình quản lý thông tin xác thực sai tiếp quản hoặc người tiêu dùng hủy bỏ - tất cả đều diễn ra trước khi có bất kỳ yêu cầu nào đến máy chủ.

Ví dụ: Một ứng dụng ngân hàng thấy nỗ lực dùng passkey giảm 30% sau bản cập nhật iOS. Nhật ký backend hiển thị ít yêu cầu hơn nhưng không có lỗi. Khả năng quan sát phía máy khách đã tìm ra nguyên nhân: iOS 18.2 đã thay đổi cách Safari hiển thị menu tự động điền và người tiêu dùng chỉ đơn giản là bỏ qua tùy chọn passkey.

Biểu đồ sau minh họa nơi tầm nhìn kết thúc cho từng phương pháp xác thực:

3.2 Các công cụ Phân tích chung Bỏ lỡ Dữ liệu Cụ thể của Passkey#

Ngay cả các công cụ chấp nhận các sự kiện tùy chỉnh (dimension tùy chỉnh của GA4, thuộc tính tùy chỉnh của Mixpanel) cũng gặp phải các giới hạn cấu trúc đối với dữ liệu passkey. Hiệu suất passkey phụ thuộc vào sự kết hợp chính xác của phiên bản hệ điều hành + phiên bản trình duyệt + trình quản lý thông tin xác thực + bộ xác thực phần cứng - hàng ngàn kết hợp độc đáo. GA4 gắn cờ các kích thước tùy chỉnh với hơn 500 giá trị duy nhất là cardinality cao, cuộn các giá trị thừa vào nhóm "(khác)" hoặc kích hoạt việc lấy mẫu - thực sự che giấu cái đuôi dài của các kết hợp thiết bị/trình duyệt/trình quản lý thông tin xác thực quan trọng nhất đối với việc gỡ lỗi passkey. Mixpanel tính phí theo khối lượng sự kiện và không cung cấp lược đồ sự kiện WebAuthn gốc.

Chúng cũng bỏ lỡ các tín hiệu chỉ có ở passkey: Thông tin xác thực có được đồng bộ hóa qua iCloud hay ràng buộc với thiết bị không? Người tiêu dùng đang cố gắng Xác thực Đa thiết bị qua mã QR? Conditional UI có được kích hoạt ở chế độ nền không? Đây là các trạng thái API trình duyệt gốc đòi hỏi công cụ được xây dựng theo mục đích để nắm bắt.

4. Những gì Khả năng Quan sát Xác thực thực sự theo dõi#

Khả năng quan sát xác thực không chỉ là "nhiều nhật ký hơn". Giá trị thực sự nằm ở bối cảnh mà nó cung cấp - điền dữ liệu bị thiếu và tính toán ngược lại hành trình đầy đủ của người tiêu dùng từ kết quả, ngay cả đối với các sự kiện đã xảy ra trước khi người tiêu dùng nhập email của họ.

4.1 Các Giai đoạn Nghi thức từ Đầu đến Cuối#

Một SDK phía máy khách được xây dựng chuyên biệt theo dõi toàn bộ vòng đời của passkey dưới dạng một hệ thống phân loại sự kiện có cấu trúc:

• Cách người tiêu dùng bắt đầu: Tự động điền qua Conditional UI, nút "Đăng nhập bằng Passkey" chuyên dụng hoặc nhập email thủ công
• Kiểm tra thiết bị: một bước thăm dò khả năng diễn ra âm thầm xác định xem thiết bị có hỗ trợ passkey hay không trước khi hiển thị bất kỳ giao diện người dùng nào
• Lựa chọn bộ xác thực: passkey được đồng bộ hóa từ trình quản lý điện thoại hoặc khóa phần cứng bên ngoài qua NFC, USB hoặc Bluetooth
• Bước sinh trắc học: Face ID, vân tay hoặc mã PIN - và liệu nó thành công, hết thời gian hay bị hủy bỏ?
• Kết quả cuối cùng: một mã lỗi WebAuthn cụ thể giải thích điều gì đã thất bại - không chỉ "thành công" hay "lỗi"

Ví dụ: Một ứng dụng bán lẻ đã theo dõi các giai đoạn này và phát hiện 22% số lần thử passkey trên Android gặp lỗi tại "Lựa chọn bộ xác thực". Nguyên nhân gốc rễ: Samsung Pass là trình quản lý thông tin xác thực mặc định trên một số thiết bị Galaxy và nó không hỗ trợ các tiện ích WebAuthn mà ứng dụng yêu cầu. Google Password Manager sẽ hoạt động, nhưng giao diện hệ điều hành của Samsung đã chuyển các yêu cầu đến Samsung Pass trước.

Sơ đồ dưới đây cho thấy các giai đoạn nghi thức này như một phễu với các điểm lỗi điển hình ở mỗi bước:

4.2 Giải thích Mã Lỗi WebAuthn cho Các Quyết định Kinh doanh#

Khi một nghi thức thất bại, trình duyệt trả về một mã lỗi cụ thể. Việc diễn giải cho kinh doanh quan trọng hơn định nghĩa kỹ thuật:

Ví dụ: Một trang web đặt chỗ du lịch thấy UnknownError tăng đột biến lên 8% đối với người dùng Firefox. 92% các lỗi đó đến từ những người tiêu dùng có kích hoạt tiện ích Bitwarden - nó đã chặn lời gọi WebAuthn và thất bại trong im lặng. Giải pháp: phát hiện Bitwarden và bỏ qua lời nhắc passkey cho đến khi lỗi tiện ích mở rộng được giải quyết.

Đặc tả WebAuthn đang phát triển. Các mã lỗi mới được đề xuất như UserCancellationError (cố ý hủy so với hết thời gian chờ) và HybridPrerequisitesError (không có Bluetooth cho chế độ đa thiết bị) sẽ thêm độ chi tiết nhiều hơn một khi các trình duyệt áp dụng chúng.

5. Tại sao Người tiêu dùng không đăng ký Passkey (và cách tìm ra lý do)#

Vấn đề khó nhất không phải là gỡ lỗi tại sao một nghi thức passkey thất bại. Đó là trả lời câu hỏi mà mọi PM đều hỏi: tại sao người tiêu dùng lại không đăng ký passkey ngay từ đầu? Đây là vấn đề trước khi đăng ký và nhật ký backend hoàn toàn mù tịt về điều này.

5.1 Điền thông tin Hành trình trước khi Người tiêu dùng cung cấp Định danh#

Một hệ thống quan sát tốt thu thập dữ liệu ngay cả khi người tiêu dùng không làm gì với passkey. Khi ai đó truy cập trang đăng nhập, SDK sẽ âm thầm kiểm tra: Thiết bị này có hỗ trợ passkey không? Conditional UI có sẵn không? Bộ xác thực nền tảng có hiện diện không?

Nếu thiết bị có khả năng nhưng người tiêu dùng lại nhấp vào "Đăng nhập bằng Mật khẩu" thay thế, hệ thống sẽ ghi lại sự kiện bỏ cuộc trước khi đăng ký. Qua hàng nghìn phiên, các sự kiện này tiết lộ các mô hình - liệu việc bỏ dở có phải là do lời nhắc bị che khuất, thiếu giáo dục về passkey hoặc do lớp phủ trình quản lý mật khẩu chặn các trường nhập biểu mẫu.

Ví dụ: Một cổng thông tin chăm sóc sức khỏe phát hiện 70% người dùng Mac phớt lờ tùy chọn passkey. Khả năng quan sát cho thấy lời nhắc passkey xuất hiện ở phần bị khuất của trang. Hầu hết người tiêu dùng không bao giờ cuộn xuống. Di chuyển lời nhắc lên phía trên trường mật khẩu đã làm tăng gấp đôi số lượng đăng ký.

5.2 Conditional UI: Điểm Lỗi vô hình#

Conditional UI cho phép passkey xuất hiện trong menu tự động điền của trình duyệt bên cạnh mật khẩu đã lưu. Nó chạy âm thầm trong nền. Backend của bạn không bao giờ biết nó đã kích hoạt trừ khi người tiêu dùng thực sự chọn passkey.

Khả năng quan sát passkey theo dõi xem Conditional UI có được gọi hay không. Nếu nó kích hoạt trên hàng nghìn thiết bị nhưng hầu như không ai chọn passkey, vấn đề là ở giao diện người dùng - không phải mật mã. Có thể danh sách tự động điền hiển thị không chính xác hoặc CSS tùy chỉnh đang ngăn chặn hành vi mặc định của trình duyệt.

Ví dụ: Một dịch vụ phát trực tuyến phương tiện phát hiện Conditional UI được kích hoạt chính xác trên 94% thiết bị hỗ trợ, nhưng tỷ lệ lựa chọn chỉ là 3%. Biểu mẫu đăng nhập đã sử dụng một trường nhập được thiết kế tùy chỉnh để chặn danh sách tự động điền mặc định của trình duyệt. Việc chuyển sang trường nhập tiêu chuẩn đã đẩy tỷ lệ chọn lên 31%.

6. Từ Dữ liệu đến Hành động: tự động ẩn ở các Thiết bị lỗi và khuyến khích Những thiết bị Tốt nhất#

Việc thu thập dữ liệu về khả năng quan sát chỉ có ý nghĩa nếu bạn hành động theo nó. Hệ thống nên nuôi một công cụ quy tắc làm thay đổi những gì người tiêu dùng thấy theo thời gian thực.

6.1 Phát hiện Lỗi hệ thống so với Hủy bỏ ngẫu nhiên#

Không phải mọi lỗi passkey đều là sự cố kỹ thuật (bug). Việc người tiêu dùng nhấn "Hủy" trên cửa sổ Face ID là chuyện thường ngày. Nhưng khi các lỗi tập trung quanh một kết hợp thiết bị/hệ điều hành/trình duyệt cụ thể, thì đó là lỗi hệ thống.

Ví dụ: Tỷ lệ thành công của passkey trên toàn cầu: 92%. Samsung Galaxy A14 trên One UI 6.0 với Chrome: 15%. Đó không phải lỗi của người dùng - đó là việc triển khai Trình quản lý Thông tin xác thực bị hỏng. Khả năng quan sát sẽ làm lộ ra điều này chỉ trong vài giờ chứ không phải vài tuần.

6.2 Tự động Ẩn ở Môi trường Lỗi#

Người tiêu dùng sẽ đổ lỗi cho ứng dụng của bạn khi đăng nhập thất bại - chứ không phải nhà sản xuất điện thoại của họ. Khi khả năng quan sát xác định được sự kết hợp giữa thiết bị và hệ điều hành nơi passkey chắc chắn sẽ hỏng, một "công tắc hủy" sẽ triệt tiêu lời nhắc passkey và định tuyến người tiêu dùng đến một phương án thay thế đáng tin cậy - liên kết ma thuật, TOTP hoặc mật khẩu - trước khi họ thấy một cửa sổ hệ điều hành bị hỏng.

Ví dụ: Một ứng dụng đi chung xe đã xác định ba mẫu Android giá rẻ với tổng tỷ lệ lỗi passkey là 82%. Sau khi ẩn passkey cho các thiết bị đó, số lượng vé hỗ trợ từ các khu vực bị ảnh hưởng đã giảm 60% trong vòng một tuần.

6.3 Khuyến khích Các nhóm Độ tin cậy Cao#

Mặt khác, nếu khả năng quan sát cho thấy người dùng macOS + Safari + Apple Silicon thành công ở mức 98%, thì nhóm đó là nhóm an toàn cho việc thúc đẩy quyết đoán - tự động gọi lời nhắc passkey, hiển thị thông báo "iCloud Keychain của bạn đã sẵn sàng để bảo mật tài khoản" hoặc đặt passkey làm mặc định với mật khẩu bị ẩn đằng sau "Tùy chọn khác".

Ví dụ: Một thị trường trực tuyến đã thúc đẩy các nhóm độ tin cậy cao bằng cách tự động kích hoạt cửa sổ nhắc đăng ký sau khi đăng nhập bằng mật khẩu. Người tiêu dùng macOS/Safari đã đăng ký ở mức 47%. Tất cả các nhóm khác (thúc đẩy ít mạnh mẽ hơn): 11%.

Cây quyết định sau tóm tắt logic tự động ẩn-hoặc-thúc đẩy được thúc đẩy bởi dữ liệu khả năng quan sát:

7. Đẩy mạnh Tỷ lệ Kích hoạt và Tỷ lệ Sử dụng#

Khả năng quan sát xác thực phục vụ hai KPI: Tỷ lệ Kích hoạt (người tiêu dùng có đang tạo passkey không?) và Tỷ lệ Sử dụng (họ có sử dụng chúng thường xuyên không?).

7.1 Nâng cao Tỷ lệ Kích hoạt#

Tỷ lệ Kích hoạt đo lường phần trăm người tiêu dùng đủ điều kiện đã tạo một passkey. Analytics chuẩn không thể tính toán điều này vì chúng không biết thiết bị nào hỗ trợ passkey. Khả năng quan sát giải quyết vấn đề này với việc thăm dò tính năng liên tục.

• Lời nhắc Sau-Nỗi-đau: khi người tiêu dùng vừa vật lộn qua một luồng đặt lại mật khẩu, ngay lập tức hiển thị lời nhắc tạo passkey. Sự bực bội đang còn mới - tỷ lệ chấp nhận là cao nhất tại khoảnh khắc này.
• Nhắc nhở Liên tục: số liệu phân tích cho thấy ngay cả lời nhắc thứ ba hoặc thứ tư vẫn chuyển đổi ở tỷ lệ hai con số, miễn là nó không làm gián đoạn người dùng.

Ví dụ: Một ứng dụng ngân hàng đã nhắc nhở tạo passkey sau mỗi luồng đặt lại mật khẩu. 34% người tiêu dùng đã tạo một passkey ngay sau khi đặt lại, so với 8% khi được nhắc trong khi đăng nhập bình thường.

7.2 Nâng cao Tỷ lệ Sử dụng#

Một người tiêu dùng có thể tạo một passkey nhưng vẫn tiếp tục gõ mật khẩu theo thói quen. Tỷ lệ Sử dụng theo dõi tần suất sử dụng passkey liên quan đến tất cả các lần đăng nhập.

• Khởi tạo UX Tốt hơn: nếu đo lường từ xa cho thấy người tiêu dùng có passkey đang hoạt động vẫn gõ tên người dùng, tính năng tự động điền đang thất bại. Một nút "One-Tap" nổi bật được đặt trước trường văn bản sẽ ngăn chặn thói quen cũ.
• Sửa Lỗi Đăng nhập Đa thiết bị: khi đăng nhập vào máy tính xách tay Windows bằng passkey trên iPhone, người tiêu dùng sẽ quét mã QR và sử dụng Bluetooth. Nếu việc hoàn thành Xác thực Đa thiết bị giảm xuống (ví dụ: xuống 42%), các hướng dẫn rõ ràng "Bật Bluetooth" và "Hướng camera vào đây" sẽ cứu vớt được nhiều nỗ lực.

Ví dụ: Một cổng thông tin bảo hiểm nhận thấy 60% người tiêu dùng đã đăng ký vẫn sử dụng mật khẩu. Tính năng tự động điền passkey được hiển thị dưới trường mật khẩu. Di chuyển nó lên trên và thêm nút "Đăng nhập bằng Face ID" đã tăng mức sử dụng passkey từ 40% lên 73% trong vòng hai tháng.

8. Cơn Ác mộng Ngày Thứ 2: Các Ứng dụng Gốc và Thay đổi Nền tảng Âm thầm#

Thiết lập passkey là phần dễ dàng. Giữ cho chúng hoạt động mượt mà trên sự hỗn loạn của thiết bị người tiêu dùng là nơi khả năng quan sát trở nên cần thiết.

8.1 Sự Phức tạp của Ứng dụng Gốc#

Passkey trong trình duyệt khá đơn giản. Trong các ứng dụng iOS và Android gốc, bề mặt cần được QA nhân lên gấp ba. Các nhà phát triển phải lựa chọn giữa API gốc (AuthenticationServices trên iOS, Credential Manager trên Android) hoặc các WebView nhúng. Mỗi hướng đi đều gặp lỗi theo một cách khác nhau.

Ví dụ: Việc triển khai ứng dụng iOS của một ứng dụng giao đồ ăn hoạt động hoàn hảo, nhưng ứng dụng Android của họ sử dụng WebView nhúng đã âm thầm loại bỏ các yêu cầu passkey trên Android 13. Nếu không có đo lường từ xa dành riêng cho nền tảng gốc, nhóm đã dành ra ba tuần để đổ lỗi cho một sự cố phía máy chủ.

8.2 Các Cập nhật Hệ điều hành Âm thầm#

Apple, Google và Microsoft liên tục tung ra các bản cập nhật. Hầu hết đều cải thiện khả năng hỗ trợ passkey, nhưng một số lại mang đến các đợt sụt giảm âm thầm làm phá vỡ logic hiện có mà không có cảnh báo.

Ví dụ: iOS 18.1 đã thay đổi cách Safari báo cáo khả năng thiết bị cho Chrome trên máy Mac. Chrome bắt đầu báo cáo sai "không có bộ xác thực nền tảng nào có sẵn", ẩn hoàn toàn tùy chọn passkey. Nhật ký backend hiển thị ít nỗ lực hơn nhưng không có lỗi. Khả năng quan sát phía máy khách đã gắn cờ cho sự kết hợp chính xác giữa hệ điều hành + trình duyệt chỉ trong vài giờ.

9. Tự Xây dựng hay Mua cho Các Nhóm CIAM#

Một khi bạn thấy nhu cầu đo lường từ xa phía máy khách, câu hỏi đặt ra là: tự xây dựng hay mua một giải pháp chuyên dụng?

9.1 Chi phí Tiềm ẩn của việc Tự Xây dựng#

Hướng tiếp cận DIY nghe có vẻ đơn giản: bọc các lệnh gọi WebAuthn bằng JavaScript, truyền các sự kiện vào hệ thống nhật ký của bạn. Trong thực tế, các công cụ chung không thể xử lý lượng lớn dữ liệu. Nhóm của bạn phải duy trì phân loại sự kiện khi hệ sinh thái phát triển - nghiên cứu các mã lỗi mới và cập nhật trình phân tích cú pháp sau mỗi bản phát hành hệ điều hành. Khi một cái gì đó bị hỏng, việc khắc phục đòi hỏi phải triển khai mã thay vì chỉ thay đổi cấu hình.

Ví dụ: Một nhà bán lẻ đã dành sáu tháng để xây dựng tính năng đo lường từ xa passkey nội bộ. Khi macOS 15.2 phá vỡ tính năng phát hiện khả năng của họ, bản vá mất hai tuần để phát hành - một chu kỳ triển khai frontend đầy đủ. Một giải pháp từ nhà cung cấp sẽ cập nhật ở phía máy chủ chỉ trong vài giờ.

9.2 Những gì Giải pháp của Nhà cung cấp mang lại#

Một nhà cung cấp chuyên biệt sẽ tổng hợp dữ liệu trên hàng nghìn ứng dụng tiêu dùng. Khi một bản cập nhật Chrome phá vỡ việc tạo passkey cho một phiên bản Android cụ thể, nhà cung cấp sẽ phát hiện nó trên toàn cầu và đẩy các phân loại lỗi đã cập nhật cho tất cả khách hàng - trước cả khi người tiêu dùng của bạn bị ảnh hưởng.

Các nền tảng của nhà cung cấp cũng cho phép bạn so sánh chuẩn: FIDO Alliance báo cáo tỷ lệ thành công cơ bản là 93%. Nếu của bạn là 75%, nền tảng sẽ hiển thị chính xác vị trí và lý do bạn chưa đạt được hiệu suất mong đợi.

10. Cách Corbado Cung cấp Khả năng quan sát Xác thực cho CIAM#

Corbado cung cấp một lớp áp dụng và quan sát passkey có sẵn. Nó tích hợp vào các hệ thống nhận dạng hiện có - Okta, Auth0, Ory, các IdP tùy chỉnh - mà không cần thay thế bất kỳ thứ gì. SDK front-end kích hoạt các sự kiện JavaScript bất đồng bộ tại các điểm cụ thể trong hành trình đăng nhập - tạo passkey, lời gọi Conditional UI, xác minh sinh trắc học, các trạng thái lỗi. Nó không bao giờ đụng đến mật khẩu, khóa riêng tư hay PII, đáp ứng những yêu cầu khắt khe nhất về quyền riêng tư.

Những gì nền tảng cung cấp:

• Phân tích Phễu: hiển thị nơi người tiêu dùng bỏ dở - trước khi nhập email, sau khi nhìn thấy lời nhắc passkey, trong lúc xác minh sinh trắc học - được phân đoạn theo hệ điều hành, trình duyệt và trình quản lý thông tin xác thực.
• Chẩn đoán bằng Văn bản Rõ ràng: dịch các mã lỗi WebAuthn thành những giải thích mà con người có thể hiểu được ("tiện ích mở rộng Bitwarden đã chặn yêu cầu passkey") và phân tách các lần hủy đơn lẻ khỏi các lỗi hệ thống.
• Cơ sở dữ liệu Lỗi Chéo hệ thống: khi một lỗi xuất hiện trên các hệ thống khác (ví dụ: Conditional UI bị hỏng trên Vivo OS), nền tảng sẽ chủ động gắn cờ báo lỗi đó cho môi trường của bạn - trước khi người tiêu dùng của bạn gặp phải.
• Bao phủ Thiết bị Toàn diện: theo dõi các khóa bảo mật phần cứng, thẻ NFC và các luồng iOS/Android gốc, không chỉ giới hạn ở các đăng nhập trên nền tảng trình duyệt.
• Độ an toàn khi Triển khai: các công tắc hủy tự động, triển khai dần theo nhóm, thử nghiệm A/B và định tuyến dự phòng thông minh.

11. Kết luận#

Khả năng quan sát xác thực cho người tiêu dùng là điểm khác biệt giữa một hệ thống có tỷ lệ áp dụng passkey dừng lại ở mức 5% và một hệ thống đạt đến đại đa số người dùng của bạn. Các nhật ký backend không thể thấy những gì xảy ra trên thiết bị của người tiêu dùng - và đối với passkey, đó là nơi 80% các lỗi xảy ra.

Bằng cách triển khai một lớp quan sát chuyên biệt, các đội ngũ CIAM chuyển từ phỏng đoán sang nắm rõ: tại sao người tiêu dùng không đăng ký, những thiết bị nào bị lỗi và những nhóm nào đã sẵn sàng cho một đợt triển khai tích cực.

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 →

FAQ#

Khả năng quan sát Xác thực là gì?#

Khả năng quan sát xác thực là quá trình thu thập và phân tích dữ liệu đo lường từ toàn bộ hành trình đăng nhập của người tiêu dùng - bao gồm cả các sự kiện phía máy khách xảy ra trước khi bất kỳ yêu cầu nào đến được backend. Nó vượt ra khỏi việc ghi nhật ký thông thường bằng cách cung cấp bối cảnh về khả năng của thiết bị, hành vi của trình quản lý thông tin xác thực, tương tác sinh trắc học và các trạng thái lỗi WebAuthn. Không giống như việc giám sát tiêu chuẩn chỉ cho bạn biết khi có thứ gì đó bị lỗi, khả năng quan sát cho bạn biết lý do tại sao.

Khả năng Quan sát Xác thực khác với Phân tích Đăng nhập tiêu chuẩn như thế nào?#

Các nền tảng phân tích đăng nhập chuẩn (nhật ký IdP, GA4, Mixpanel) chỉ nắm bắt kết quả phía máy chủ và các sự kiện frontend chung chung như nhấn nút. Khả năng quan sát xác thực nắm bắt các lời gọi API trình duyệt gốc, các tương tác với trình quản lý thông tin xác thực và kết quả hiển thị sinh trắc học trên thiết bị của người tiêu dùng. Nó xử lý dữ liệu cardinality cao do passkey tạo ra - hàng nghìn sự kết hợp phần cứng, hệ điều hành, trình duyệt và trình quản lý xác thực độc đáo - mà các nền tảng phân tích chung thường bỏ qua.

Tại sao các Đợt triển khai Passkey thường bị chững lại ở mức Tỷ lệ áp dụng thấp?#

Hầu hết các đợt triển khai passkey bị mắc kẹt ở tỷ lệ áp dụng từ 5% đến 15% vì các đội ngũ thiếu tầm nhìn vào các thất bại phía máy khách và việc từ bỏ đăng ký từ sớm. Người tiêu dùng có thể sở hữu thiết bị hỗ trợ passkey nhưng không bao giờ thấy lời nhắc passkey (vấn đề về vị trí hiển thị UI), bị nhầm lẫn bởi các lớp phủ trình quản lý mật khẩu chồng chéo, hoặc gặp phải các lỗi ở cấp độ thiết bị một cách âm thầm. Nếu không có đo lường phía máy khách, những vấn đề này hoàn toàn không thể quan sát được.

Vấn đề Mù Thông tin Trước định danh (Pre-Identifier Blindness) trong CIAM là gì?#

Sự mù lòa trước định danh là việc các hệ thống backend không có khả năng nhìn thấy những gì diễn ra trước khi người tiêu dùng nhập email hoặc tên người dùng của họ. Trong CIAM, người tiêu dùng là ẩn danh cho đến khi họ tự xác minh danh tính. Nếu họ rời bỏ trang đăng nhập trước thời điểm đó - do giao diện khó hiểu, xung đột tiện ích mở rộng hoặc Conditional UI bị hỏng - không một nhật ký backend nào sẽ bắt được sự kiện này. Khả năng quan sát xác thực lấp đầy khoảng trống này bằng cách kiểm tra các tính năng chạy ngầm ở phía máy khách ngay khi trang được tải.

Khả năng Quan sát giúp như thế nào trong việc Áp dụng Passkey (không chỉ là Gỡ lỗi)?#

Khả năng quan sát làm được nhiều thứ hơn ngoài chẩn đoán những nghi thức bị hỏng. Nó xác định các phân khúc người tiêu dùng có tỷ lệ thành công khi sử dụng passkey cao nhất và tạo điều kiện cho các biện pháp khuyến khích dựa trên dữ liệu - tự động nhắc đăng ký cho các nhóm thiết bị có độ tin cậy cao. Nó cũng chỉ ra thời điểm tốt nhất để nhắc (ví dụ: ngay sau khi đặt lại mật khẩu do bực bội) và chứng minh qua dữ liệu rằng các lời nhắc liên tục, không gây trở ngại có thể chuyển đổi thành công ở tỷ lệ hai chữ số, kể cả trong lần thử thứ ba hoặc thứ tư.

Các Lỗi Passkey phổ biến nhất trong Môi trường Thực tế là gì?#

Các lỗi phổ biến nhất trong triển khai CIAM thực tế là: một số kết hợp thiết bị/hệ điều hành cụ thể với các triển khai Trình quản lý Thông tin xác thực bị hỏng (ví dụ: điện thoại Android giá rẻ từ các OEM khu vực), các tiện ích mở rộng của trình quản lý mật khẩu từ bên thứ ba (Bitwarden, 1Password, LastPass) ngăn chặn các lời gọi WebAuthn và lỗi một cách âm thầm, các bản cập nhật HĐH gây sụt giảm hiệu năng âm thầm thay đổi cách các trình duyệt báo cáo về khả năng của thiết bị, và Conditional UI không hiển thị do các trường dữ liệu tùy chỉnh hoặc xung đột CSS.