---
url: 'https://www.corbado.com/vi/blog/passkey-day-2-problems'
title: 'Các vấn đề Passkey Ngày 2: 5 rủi ro sau khi ra mắt'
description: 'Passkey rất tuyệt vời cho đến khi bạn triển khai sai. Tìm hiểu 5 vấn đề Ngày 2 xoay quanh việc khôi phục, UX đa thiết bị, ứng dụng gốc, sự áp dụng và thay đổi nền tảng.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2026-05-27T11:05:01.457Z'
lastModified: '2026-05-27T11:06:20.822Z'
keywords: 'các vấn đề passkey ngày 2, thách thức vận hành passkey, rủi ro passkey sau khi ra mắt, vấn đề triển khai passkey, có nên triển khai passkey không'
category: 'Passkeys Strategy'
---

# Các vấn đề Passkey Ngày 2: 5 rủi ro sau khi ra mắt

## Key Facts

- **Mức độ áp dụng thấp** là nguyên nhân thất bại phổ biến nhất: các doanh nghiệp bỏ qua chiến lược triển khai sẽ thấy tỷ lệ sử dụng passkey dưới 5% dù triển khai kỹ thuật tốt, làm lãng phí toàn bộ khoản đầu tư kỹ thuật.
- **Thiết kế dự phòng khôi phục** quyết định liệu bạn có tạo lại rủi ro lừa đảo (phishing) hay khóa tài khoản người dùng ở quy mô lớn hay không. Đặt lại mật khẩu qua email hoàn toàn vô hiệu hóa các passkey chống lừa đảo nếu kẻ tấn công kiểm soát được hộp thư đến.
- **Thay đổi nền tảng** phá vỡ passkey một cách âm thầm, như lỗi iOS 26.2 khi `isUserVerifyingPlatformAuthenticatorAvailable()` trả về false trên tất cả các trình duyệt không phải Safari, yêu cầu phải cập nhật logic phát hiện.
- **Độ phức tạp của ứng dụng gốc** làm tăng gấp ba lần bề mặt QA trên web, iOS và Android, với các mã lỗi đặc thù theo nền tảng và chu kỳ xét duyệt trên cửa hàng ứng dụng ngăn chặn việc khắc phục khẩn cấp các lỗi hồi quy passkey.

## 1. Giới thiệu: Rủi ro của passkey sau khi ra mắt

**Đừng triển khai passkey.**

Ít nhất là không phải bằng mọi giá và không phải nếu bạn không có đủ nguồn lực để làm việc đó một cách bài bản.

Đúng, passkey là điều tuyệt vời nhất xảy ra với xác thực người tiêu dùng trong vòng một thập kỷ qua.
Đúng, chúng loại bỏ lừa đảo. Đúng, chúng có thể cải thiện đáng kể UX. Nhưng
passkey được thực hiện sai cách cũng có thể gây ra nhiều tác hại.

Triển khai một máy chủ WebAuthn không quá phức tạp. Thách thức thực sự là mọi thứ xung quanh nó. Vận hành passkey hiệu quả ở quy mô lớn cần phải lập kế hoạch trước. Bạn cần suy nghĩ về tất cả các vấn đề "Ngày 2" - những thực tế vận hành chỉ bộc lộ sau khi bạn đã bắt đầu triển khai passkey.

Bài viết này đề cập đến năm vấn đề Ngày 2 liên tục phá hoại các dự án passkey. Nếu bạn không thể giải quyết tất cả, bạn chưa sẵn sàng ra mắt passkey. Nếu có thể, bạn sẽ xây dựng một hệ thống xác thực an toàn hơn và dễ sử dụng hơn bất cứ điều gì mà mật khẩu có thể mang lại.

## 2. Vấn đề passkey Ngày 2 là gì?

Trong kỹ thuật phần mềm, "Ngày 1" là khi bạn xây dựng và ra mắt. "Ngày 2" là khi bạn vận hành, bảo trì và mở rộng những gì đã ra mắt. Đối với passkey, Ngày 1 có thể khá đơn giản:

- tích hợp máy chủ WebAuthn vào stack công nghệ doanh nghiệp của bạn
- thêm các luồng frontend và ra mắt.

Hầu hết các nhóm có thể thiết lập một hệ thống passkey cơ bản chạy trong vài ngày hoặc vài tuần.

Ngày 2 là nơi các dự án thất bại. Đó là lúc những người dùng thực trên thiết bị thực với các trường hợp ngoại lệ thực tế tương tác với hệ thống passkey của bạn. Đó là lúc bạn phát hiện ra bản demo hào nhoáng hoạt động hoàn hảo trên MacBook của mình lại bị hỏng trên máy tính xách tay Windows chạy Chrome sau proxy của công ty. Đó là lúc nhóm hỗ trợ của bạn tràn ngập các yêu cầu "Tôi không thể đăng nhập được nữa".

Khoảng cách giữa một bản demo passkey hoạt động được và một triển khai passkey cấp sản xuất là rất lớn. Trước đây, chúng tôi đã đề cập đến các cạm bẫy triển khai kỹ thuật và những lý do chiến lược khiến các dự án passkey thất bại. Bài viết này tập trung cụ thể vào những gì xảy ra sau khi bạn đi vào hoạt động từ góc độ vận hành.

Dưới đây là năm vấn đề Ngày 2 mà chúng ta sẽ đề cập:

- [Vấn đề 1: Khôi phục và Dự phòng rất khó bảo mật](#3-issue-1-recovery-and-fallback-are-hard-to-secure)
- [Vấn đề 2: Các trường hợp ngoại lệ đa thiết bị và đa hệ sinh thái phá vỡ luồng passkey](#4-issue-2-cross-device-and-cross-ecosystem-edge-cases-break-passkey-flows)
- [Vấn đề 3: Các ứng dụng gốc (Native Apps) nhân lên độ phức tạp của passkey](#5-issue-3-native-apps-multiply-passkey-complexity)
- [Vấn đề 4: Áp dụng là vấn đề của sản phẩm, không phải là vấn đề công nghệ](#6-issue-4-adoption-is-a-product-problem-not-a-tech-problem)
- [Vấn đề 5: Những thay đổi của nền tảng phá vỡ passkey một cách âm thầm](#7-issue-5-platform-changes-break-passkeys-silently)

## 3. Vấn đề 1: Khôi phục và Dự phòng rất khó bảo mật

Nếu bạn không thiết kế khôi phục và dự phòng một cách bài bản, bạn sẽ khóa tài khoản người dùng ở quy mô lớn hoặc âm thầm mang trở lại chính những luồng dễ bị lừa đảo mà bạn muốn loại bỏ.

### 3.1 Rủi ro khóa tài khoản ở quy mô lớn

Hãy xem xét một người dùng đăng ký passkey trên iPhone của họ, sau đó làm mất iPhone đó. Thông thường, một phần lớn các trường hợp khôi phục này hiện đang được xử lý bởi trình quản lý thông tin xác thực (rất có thể là iCloud Keychain trên iPhone). Chừng nào người dùng còn quyền truy cập vào tài khoản Apple của họ, họ vẫn có sẵn các passkey được đồng bộ hóa để đăng nhập trên thiết bị mới. Nhưng nếu họ không còn quyền truy cập vào tài khoản đám mây đó nữa thì sao? Đây là lúc lộ trình khôi phục thông thường của bạn phát huy tác dụng.

Giả sử bạn cho rằng khóa riêng tư vẫn có sẵn trên thiết bị mà người dùng cố gắng đăng nhập, vì vậy bạn bắt đầu quy trình đăng nhập WebAuthn. Điều này sẽ dẫn đến một hộp thoại hệ điều hành / trình duyệt yêu cầu người dùng "đăng nhập bằng passkey của bạn trên thiết bị khác". Về cơ bản, người dùng hiện bị khóa khỏi tài khoản của họ. Không có thiết bị nào khác lưu trữ passkey. Người dùng vô cùng bối rối. Nhân con số này với hàng ngàn người dùng và bạn sẽ gặp khủng hoảng hỗ trợ.

Phản ứng phổ biến là thêm đặt lại tài khoản dựa trên email làm giải pháp dự phòng. Nhưng điều này đi ngược lại mục đích của passkey: bạn vừa đưa trở lại một kênh khôi phục có thể bị lừa đảo. Một kẻ tấn công có thể xâm phạm email của người dùng giờ đây có thể vượt qua toàn bộ hệ thống passkey chống lừa đảo của bạn.

### 3.2 Thiết kế dự phòng không đưa lừa đảo quay trở lại

Theo quan điểm của chúng tôi, cách tiếp cận đúng là khôi phục theo nhiều lớp:

1. **Passkey được đồng bộ hóa** là chiến lược chính: đảm bảo người dùng tạo các passkey được đồng bộ hóa (thông qua iCloud Keychain, Google Password Manager hoặc nhà cung cấp passkey của bên thứ ba) để việc mất thiết bị không đồng nghĩa với mất thông tin xác thực
2. **Xác thực đa thiết bị** như lớp thứ hai: cho phép người dùng xác thực từ một thiết bị khác nơi có sẵn một passkey khác bằng cách quét mã QR
3. **Xác minh danh tính (IDV)** như lớp thứ ba: cung cấp IDV tự động với kiểm tra tính sống (liveness checks) thay vì quay lại mật khẩu/OTP.
4. **Thông tin xác thực có thể xác minh kỹ thuật số (Digital verifiable credentials)** như lớp thứ tư: đây là phiên bản khôi phục tài khoản an toàn nhất, bảo vệ quyền riêng tư và thân thiện với UX nhất. Điều này cho phép người dùng sử dụng thông tin xác thực có thể xác minh kỹ thuật số của họ (ví dụ: ID quốc gia kỹ thuật số hoặc mDL) để xác minh danh tính của họ bằng cách sử dụng các API tiêu chuẩn (ví dụ: Digital Credentials API). Công nghệ này khá mới và mức độ áp dụng chưa cao nhưng nó sẽ đóng vai trò quan trọng trong những tháng và năm tới.

Nói chung, bạn cần quyết định những lớp khôi phục tài khoản nào có thể được biện minh từ góc độ chi phí / ma sát. Ví dụ: trong ngành [bán lẻ](https://www.corbado.com/passkeys-for-e-commerce) / [thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce), bạn có thể chỉ cung cấp hai lớp đầu tiên và chấp nhận rủi ro lừa đảo do lý do tài chính. Trong các ngành khác, nơi bảo mật quan trọng hơn, bạn đi đến lớp 3 và lớp 4.

Mỗi lớp thêm độ phức tạp. Bạn cần quyết định trường hợp sử dụng của mình yêu cầu các lớp nào, xây dựng chúng, thử nghiệm chúng trên tất cả các kết hợp thiết bị và theo dõi việc sử dụng chúng. Đây là khối lượng công việc lớn hơn đáng kể so với việc tích hợp WebAuthn ban đầu.

### 3.3 Những gì hầu hết các nhóm làm sai

Hầu hết các nhóm hoặc đơn giản hóa quá mức việc khôi phục (quay lại mật khẩu hoặc SMS OTP) hoặc làm phức tạp quá mức (ví dụ: yêu cầu khóa bảo mật phần cứng cho mọi lần khôi phục). Sự cân bằng phù hợp phụ thuộc vào mô hình rủi ro, cơ sở người dùng và các yêu cầu quản lý của bạn. Làm sai có nghĩa là làm suy yếu vị thế bảo mật của bạn hoặc tạo ra quá nhiều ma sát khiến người dùng từ bỏ quy trình.

## 4. Vấn đề 2: Các trường hợp ngoại lệ đa thiết bị và đa hệ sinh thái phá vỡ luồng passkey

Người dùng của bạn không sống trong một thế giới chỉ toàn Apple sạch sẽ. Họ chuyển đổi thiết bị, trộn lẫn Windows với iOS, sử dụng các trình duyệt khác nhau và làm việc trên các thiết lập do công ty quản lý.
Đó là nơi các luồng passkey bị phá vỡ nếu bạn chưa lên kế hoạch cho nó.

### 4.1 Sự phân mảnh hệ sinh thái là có thật

Hệ sinh thái passkey trải rộng trên ba nền tảng chính (Apple, Google và Microsoft), nhiều trình duyệt (Chrome, Safari, Firefox và Edge), hàng chục nhà cung cấp passkey / trình quản lý thông tin xác thực (ví dụ: 1Password, Bitwarden, Dashlane và những trình khác) và vô số sự kết hợp hệ điều hành/trình duyệt/thiết bị. Mỗi sự kết hợp có thể hoạt động hơi khác nhau, ví dụ:

- **Apple** đồng bộ hóa passkey theo mặc định qua iCloud Keychain trên iOS, iPadOS và macOS nhưng không đồng bộ với Windows hoặc Android
- **Google** đồng bộ hóa qua Google Password Manager trên Android và Chrome nhưng trải nghiệm trên iOS thì khác (bạn cần thiết lập thủ công)
- **Windows** có hành vi passkey riêng khác biệt đáng kể so với các nền tảng khác
- **Trình quản lý mật khẩu** xử lý việc tạo và lựa chọn passkey theo cách khác nhau, đôi khi xung đột với lời nhắc nguyên bản của nền tảng

### 4.2 Các luồng xác thực đa thiết bị

Khi một người dùng tạo passkey trên iPhone của họ nhưng muốn đăng nhập trên máy tính xách tay Windows, họ có thể sử dụng xác thực đa thiết bị (thường qua mã QR và Bluetooth). Luồng này hoạt động nhưng rất mong manh:

- Nó yêu cầu bật Bluetooth trên cả hai thiết bị
- Tường lửa của công ty và chính sách MDM có thể can thiệp do có một đường hầm (tunnel) được thiết lập trong nền
- UX thay đổi đáng kể giữa các trình duyệt
- Người dùng thường không hiểu chuyện gì đang xảy ra hoặc tại sao họ lại quét mã QR

Chúng tôi đã chứng kiến tận mắt những trường hợp ngoại lệ này trên hàng nghìn sự kết hợp thiết bị. Nếu bạn đang xây dựng passkey nội bộ, bạn cần kiểm tra và xử lý mọi trường hợp trong số đó. Nếu không thể, người dùng của bạn sẽ gặp lỗi mà nhóm hỗ trợ không thể giải thích.

### 4.3 Trình duyệt và sự không nhất quán của Hệ điều hành

Ngay cả trên cùng một thiết bị, các trình duyệt khác nhau hoạt động khác nhau. Chrome trên macOS hiển thị các hộp thoại passkey khác với Safari trên macOS. Firefox có hành vi riêng của nó.
Client hints và phát hiện user agent trở nên quan trọng để cung cấp luồng chính xác cho đúng người dùng, nhưng việc phân tích cú pháp chúng một cách chính xác trên mọi sự kết hợp là một gánh nặng bảo trì không bao giờ kết thúc.

## 5. Vấn đề 3: Các ứng dụng gốc (Native Apps) nhân lên độ phức tạp của passkey

Thử nghiệm và QA passkey vốn đã là một thách thức đối với các ứng dụng web (chúng tôi đề cập chi tiết trong [Vấn đề 5: Thay đổi nền tảng](#7-issue-5-platform-changes-break-passkeys-silently)). Nhưng nếu sản phẩm của bạn cũng có ứng dụng iOS và Android gốc, độ phức tạp sẽ nhân lên do các quyết định kiến trúc và hành vi cụ thể của nền tảng mà các nhóm chỉ làm web không bao giờ phải đối mặt.

### 5.1 Các quyết định Native vs. WebView

Quyết định đầu tiên là triển khai passkey dạng native hay thông qua WebView. Mỗi cách tiếp cận đều có sự đánh đổi:

| Khía cạnh | Triển khai Native | Triển khai WebView |
| --- | --- | --- |
| **Chất lượng UX** | Tốt nhất, cảm giác native trên nền tảng | Phụ thuộc vào loại WebView |
| **Bảo trì** | Các codebase riêng biệt cho iOS và Android | Logic web dùng chung |
| **Yêu cầu nền tảng** | Phải theo dõi thay đổi SDK của Apple/Google | Phải xử lý vấn đề hỗ trợ passkey trong WebView |
| **Độ phức tạp** | Cao (các API dành riêng cho nền tảng) | Trung bình (nhưng loại WebView rất quan trọng) |

Riêng trên iOS, bạn có thể chọn giữa WKWebView, SFSafariViewController, SFAuthenticationSession và ASWebAuthenticationSession - mỗi loại có đặc điểm hỗ trợ passkey khác nhau. Trên Android, Chrome Custom Tabs hoạt động khác với WebViews tiêu chuẩn. Đây là những quyết định mà các nhóm web-only không bao giờ phải đưa ra và mỗi lựa chọn lại tạo ra bề mặt bảo trì riêng.

### 5.2 Hành vi đặc thù nền tảng trong các ứng dụng gốc

Ngoài quyết định kiến trúc, iOS và Android xử lý passkey khác nhau ở cấp hệ điều hành:

- **iOS** tích hợp passkey sâu vào trình quản lý thông tin xác thực hệ thống, với các hành vi tự động điền (autofill) cụ thể có thể thay đổi theo từng phiên bản iOS
- **Android** định tuyến các yêu cầu passkey thông qua Credential Manager API, API này tương tác với nhiều nhà cung cấp passkey cùng lúc
- Các trạng thái lỗi, hành vi hết thời gian chờ và lời nhắc người dùng khác nhau giữa các nền tảng. Khi người dùng hủy, trên web báo lỗi `NotAllowedError`, trên iOS là `SimpleAuthenticationServices.AuthorizationError` và trên Credential Manager của Android là `User cancelled the operation` - hãy xem bản đồ lỗi WebAuthn trên môi trường production để biết ánh xạ lỗi đa nền tảng đầy đủ
- Chu kỳ đánh giá của cửa hàng ứng dụng làm chậm trễ khi bạn cần phát hành các bản sửa lỗi khẩn cấp cho sự cố hồi quy của passkey

### 5.3 Bề mặt QA nhân ba

Nếu bạn vận hành cả ứng dụng web và ứng dụng native, bạn không chỉ nhân đôi công sức QA mà là nhân ba. Web, iOS và Android đều hoạt động như các môi trường passkey riêng biệt cần thử nghiệm từ đầu đến cuối và giám sát độc lập. Và không giống như web, nơi bạn có thể triển khai bản sửa lỗi ngay lập tức, các bản sửa lỗi ứng dụng gốc bị kiểm soát bởi chu kỳ đánh giá của cửa hàng ứng dụng.

## 6. Vấn đề 4: Áp dụng là vấn đề của sản phẩm, không phải là vấn đề công nghệ

"Có hỗ trợ passkey" không đồng nghĩa với "được sử dụng passkey". Nếu bạn không có chiến lược triển khai và đo lường, mức độ áp dụng sẽ gây thất vọng và dự án sẽ bị coi là thất bại trong nội bộ.

### 6.1 Tại sao mức độ áp dụng thấp giết chết dự án của bạn

Chúng tôi đã đề cập sâu rộng đến vấn đề này trong bài viết về lý do các triển khai passkey thất bại: nếu người dùng không chuyển sang dùng passkey, dự án đã thất bại. Mật khẩu vẫn chiếm ưu thế, chi phí SMS OTP vẫn cao, rủi ro lừa đảo vẫn tồn tại và tổ chức của bạn không nhận được lợi tức từ khoản đầu tư kỹ thuật đáng kể.

Cơ sở kinh doanh cho việc áp dụng passkey là rất mạnh mẽ nhưng chỉ khi việc áp dụng thực sự xảy ra. Chúng tôi đã thấy các doanh nghiệp ra mắt passkey với việc triển khai kỹ thuật tuyệt vời nhưng mức độ áp dụng chưa đến 5% vì không ai nghĩ đến chiến lược ra mắt và áp dụng.

### 6.2 Việc áp dụng đòi hỏi công việc sản phẩm có chủ ý

Thúc đẩy việc áp dụng passkey là một thách thức sản phẩm đòi hỏi:

- **Đăng ký lũy tiến**: thúc giục người dùng tạo passkey vào những thời điểm thích hợp (ví dụ: sau khi đăng nhập thành công, trong quá trình đánh giá bảo mật tài khoản)
- **Giao tiếp người dùng rõ ràng**: giải thích passkey là gì và tại sao chúng lại tốt hơn, bằng ngôn ngữ mà người dùng phi kỹ thuật có thể hiểu
- **Nhắc nhở nhận biết thiết bị**: chỉ cung cấp việc tạo passkey khi thiết bị của người dùng thực sự hỗ trợ tốt tính năng đó, tránh những trải nghiệm khó chịu trên các cấu hình không được hỗ trợ
- **Cơ sở hạ tầng đo lường**: theo dõi tỷ lệ tạo passkey, tỷ lệ đăng nhập thành công, tỷ lệ dự phòng và tỷ lệ từ bỏ để xác định và khắc phục các điểm tắc nghẽn

### 6.3 Mức độ áp dụng "Tốt" trông như thế nào

Dựa trên kinh nghiệm của chúng tôi với các triển khai passkey quy mô lớn, đây là những gì doanh nghiệp nên nhắm tới:

| Số liệu | Yếu | Chấp nhận được | Mạnh |
| --- | --- | --- | --- |
| **Tỷ lệ tạo passkey** (trên số người dùng đủ điều kiện) | <10% | 10-60% | >60% |
| **Tỷ lệ đăng nhập bằng passkey** (trên tổng số lượt đăng nhập) | <5% | 5-40% | >40% |

Nếu số liệu áp dụng của bạn trông giống như cột "Yếu" sau ba tháng, dự án đang gặp rắc rối. Nếu không có phân tích để đo lường điều này, bạn thậm chí sẽ không biết.

## 7. Vấn đề 5: Những thay đổi của nền tảng phá vỡ passkey một cách âm thầm

Cập nhật hệ điều hành và trình duyệt thay đổi lời nhắc, hành vi tự động điền và luồng dự phòng. Nếu bạn không có giám sát liên tục, bạn sẽ gặp lỗi hồi quy và nhận vé hỗ trợ mà không có cảnh báo.

Chúng tôi vừa xuất bản một tổng quan toàn diện về các lỗi WebAuthn xảy ra trong môi trường sản xuất.

### 7.1 Tại sao Passkey lại bị ảnh hưởng duy nhất bởi những thay đổi nền tảng

Không giống như mật khẩu (chỉ là chuỗi văn bản mà máy chủ của bạn xác thực), passkey phụ thuộc vào sự tích hợp sâu với hệ điều hành, trình duyệt và trình quản lý thông tin xác thực. Khi Apple ra mắt phiên bản iOS mới, lời nhắc tạo passkey có thể trông khác. Khi Chrome cập nhật logic tự động điền, quy trình đăng nhập của bạn có thể bị hỏng. Khi một trình quản lý mật khẩu phát hành phiên bản mới, nó có thể bắt đầu chặn các yêu cầu passkey theo những cách mà bạn không lường trước được.

Một ví dụ gần đây là lỗi iOS 26.2 khi `isUserVerifyingPlatformAuthenticatorAvailable()` trả về `false` trên tất cả các trình duyệt không phải Safari (Chrome, Edge, Firefox), đòi hỏi logic phát hiện nhận thức nền tảng sử dụng `getClientCapabilities()` như một cách giải quyết tạm thời.

### 7.2 Giám sát không phải là tùy chọn

Để đảm bảo bạn nhận biết được tất cả các lỗi tiềm ẩn và theo dõi mức độ áp dụng, bạn cần thiết lập nền tảng quan sát xác thực (observability stack) của mình. Chúng tôi khuyên bạn nên có ít nhất những điều sau đây:

- **Phân tích xác thực theo thời gian thực**: theo dõi tỷ lệ thành công và thất bại theo sự kết hợp hệ điều hành, trình duyệt và nhà cung cấp passkey
- **Giám sát theo phiên bản**: phát hiện khi một phiên bản hệ điều hành hoặc trình duyệt mới gây ra sự gia tăng đột biến về lỗi hoặc việc sử dụng dự phòng. Phân biệt giữa các lỗi dự kiến (người dùng hủy sẽ hiển thị dưới dạng `NotAllowedError`) và lỗi không mong muốn (`AbortError` tăng vọt do lỗi đồng thời hoặc lỗi passkey mới trong Credential Manager sau khi cập nhật Android)
- **Cảnh báo**: nhận thông báo trước khi người dùng của bạn bắt đầu tạo vé hỗ trợ
- **Khả năng phản hồi nhanh**: khả năng tung ra bản sửa lỗi hoặc vô hiệu hóa passkey cho các thiết bị bị ảnh hưởng một cách nhanh chóng

Đây là loại cơ sở hạ tầng phân tích xác thực mà hầu hết các nhóm không xây dựng cho đến khi họ gặp sự cố. Đến lúc đó, lòng tin của người dùng và uy tín nội bộ của dự án đã bị tổn hại.

### 7.3 Chi phí bảo trì liên tục

Chi phí thực sự của việc triển khai passkey không nằm ở phần xây dựng ban đầu. Đó là bảo trì liên tục:

- Giám sát các thay đổi của nền tảng trên iOS, Android, Windows, macOS và tất cả các trình duyệt chính
- Thử nghiệm từng bản cập nhật để tìm lỗi hồi quy
- Cập nhật SDK frontend của bạn khi API trình duyệt thay đổi
- Duy trì khả năng tương thích với một hệ sinh thái ngày càng tăng của các nhà cung cấp passkey
- Ghi lại và thông báo các thay đổi cho nhóm hỗ trợ của bạn

## 8. Khi nào bạn nên (hoặc không nên) triển khai passkey

Căn cứ vào những vấn đề Ngày 2 này, đây là đánh giá trung thực về thời điểm bạn nên và không nên ra mắt passkey.

### 8.1 Không triển khai passkey nếu

- Bạn chưa có chiến lược dự phòng và khôi phục rõ ràng
- Bạn chưa thử nghiệm trên các kết hợp thiết bị mà người dùng của bạn thực sự sử dụng
- Bạn có ứng dụng gốc nhưng không có kế hoạch cho QA liên tục đặc thù theo nền tảng
- Bạn không có cơ sở hạ tầng phân tích để đo lường việc áp dụng
- Bạn không thể phân bổ nguồn lực kỹ thuật cho việc bảo trì liên tục
- Bạn đang triển khai passkey hoàn toàn vì mục đích tuân thủ mà không có kế hoạch phù hợp

Dốc toàn lực vì các lý do quy định mà không lập kế hoạch phù hợp có thể làm tăng chi phí đáng kể. Một hệ thống passkey triển khai kém còn tệ hơn là không có hệ thống nào: nó làm xói mòn lòng tin của người dùng, tạo thêm gánh nặng hỗ trợ và mang lại cho các bên liên quan nội bộ lý do để hủy bỏ dự án.

### 8.2 Triển khai passkey nếu

- Bạn đã lên kế hoạch cho tất cả năm vấn đề Ngày 2 được mô tả ở trên
- Bạn có các khả năng về sản phẩm, kỹ thuật, bảo mật và phân tích để hỗ trợ việc triển khai liên tục
- Bạn đã lập ngân sách cho việc bảo trì liên tục, chứ không chỉ là phần xây dựng ban đầu
- Bạn có chiến lược triển khai theo từng giai đoạn với mục tiêu áp dụng rõ ràng
- Bạn đang làm việc với một đối tác như Corbado để xử lý các phức tạp vận hành thay bạn

### 8.3 Quyết định tự xây dựng hay mua

Những vấn đề Ngày 2 được mô tả trong bài viết này chính là lý do nhiều doanh nghiệp chọn mua thay vì tự xây dựng cơ sở hạ tầng passkey. Xây dựng một máy chủ WebAuthn là phần dễ. Việc vận hành một hệ thống passkey cấp sản phẩm trên hàng ngàn kết hợp thiết bị, với việc khôi phục, giám sát và phân tích mức độ áp dụng phù hợp, chính là ranh giới giữa một bản demo và một hệ thống triển khai thực sự.

## 9. Cách Corbado giải quyết các vấn đề passkey Ngày 2

Corbado tồn tại chính vì những vấn đề Ngày 2 thực sự khó khăn. Nền tảng của chúng tôi xử lý các phức tạp vận hành để bạn không phải tự xây dựng và bảo trì.

### 9.1 Khôi phục và Dự phòng

Corbado cung cấp các luồng khôi phục có sẵn (out-of-the-box) với mức độ bảo mật thích ứng. Từ chiến lược passkey được đồng bộ hóa đến xác thực đa thiết bị và xác minh danh tính tự động. Logic khôi phục được tích hợp sẵn và liên tục được cập nhật.

### 9.2 Khả năng tương thích đa thiết bị

SDK frontend của chúng tôi đã được kiểm tra trước trên hàng ngàn kết hợp hệ điều hành, trình duyệt và nhà cung cấp passkey. Phát hiện thiết bị, xử lý giao diện có điều kiện (conditional UI) và định tuyến dự phòng diễn ra tự động. Khi một phiên bản trình duyệt mới làm hỏng điều gì đó, chúng tôi sẽ sửa nó trong SDK trước khi người dùng của bạn nhận ra.

### 9.3 Hỗ trợ ứng dụng gốc

Corbado hỗ trợ việc triển khai passkey trên cả môi trường native và WebView thông qua các SDK trừu tượng hóa sự khác biệt nền tảng. Bạn có thể tập trung vào trải nghiệm UX của ứng dụng trong khi chúng tôi xử lý phần kỹ thuật passkey xuyên suốt trên iOS và Android.

### 9.4 Phân tích áp dụng

Bảng điều khiển phân tích của chúng tôi theo dõi mọi số liệu quan trọng: tỷ lệ tạo passkey, tỷ lệ đăng nhập thành công, tỷ lệ dự phòng và số liệu phân tích theo cấp độ thiết bị. Bạn sẽ có được những hiểu biết thực tế để thúc đẩy sự áp dụng, thay vì chỉ là dữ liệu thô.

### 9.5 Giám sát Thay đổi Nền tảng

Corbado liên tục theo dõi các thay đổi hệ điều hành và trình duyệt ảnh hưởng đến passkey. SDK của chúng tôi được cập nhật một cách chủ động. Việc triển khai passkey của bạn vẫn ổn định ngay cả khi bối cảnh nền tảng thay đổi.

## 10. Kết luận

Passkey là tiêu chuẩn vàng của xác thực. Điều đó không cần bàn cãi. Nhưng con đường từ "hỗ trợ passkey" đến "passkey hoạt động ổn định ở quy mô lớn" được lát bằng những vấn đề Ngày 2 mà hầu hết các đội nhóm thường đánh giá thấp.

Năm vấn đề mà chúng tôi đã đề cập (khôi phục, các trường hợp ngoại lệ đa thiết bị, độ phức tạp của ứng dụng gốc, mức độ áp dụng và các thay đổi của nền tảng) không hề hiếm gặp. Đó là những thách thức hoạt động cốt lõi của bất kỳ hệ thống passkey thương mại nào. Phớt lờ chúng không làm chúng biến mất. Nó chỉ có nghĩa là người dùng sẽ tự khám phá ra chúng trước bạn.

Khuyến nghị chân thành của tôi: nếu bạn không có bí quyết và nguồn lực để triển khai passkey đúng cách, thì đừng ra mắt nó. Hãy đầu tư vào năng lực nội tại (sản phẩm, kỹ thuật, an ninh và phân tích) hoặc hợp tác với một đối tác đã giải quyết được những vấn đề này. Kết quả tồi tệ nhất là một đợt triển khai passkey nửa vời và sau đó bị hủy bỏ chỉ vì không ai có kế hoạch cho Ngày 2.

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

### 5 vấn đề Ngày 2 khiến các dự án passkey thất bại sau khi ra mắt là gì?

Năm vấn đề về vận hành là các luồng khôi phục và dự phòng không an toàn, các trường hợp ngoại lệ trong hệ sinh thái đa thiết bị, độ phức tạp của ứng dụng gốc, mức độ áp dụng của người dùng thấp và các lỗi hồi quy âm thầm từ các bản cập nhật của hệ điều hành và trình duyệt. Hầu hết các nhóm tập trung vào việc tích hợp WebAuthn ban đầu và đánh giá thấp những thách thức sau khi ra mắt này, đó là lý do tại sao nhiều dự án passkey bị hủy bỏ hoặc âm thầm từ bỏ trong nội bộ.

### Làm cách nào để xử lý xác thực passkey đa thiết bị cho người dùng doanh nghiệp trên Windows đã đăng ký trên iPhone?

Người dùng có thể xác thực qua luồng xác thực đa thiết bị quét mã QR và Bluetooth, nhưng điều này yêu cầu bật Bluetooth trên cả hai thiết bị và có thể bị chặn bởi các chính sách MDM của công ty và tường lửa. Trải nghiệm người dùng (UX) khác nhau đáng kể giữa các trình duyệt và người dùng thường không hiểu tại sao họ lại quét mã QR, làm cho việc định tuyến dự phòng nhận biết thiết bị và giao tiếp rõ ràng trở nên quan trọng đối với việc triển khai tại doanh nghiệp.

### Các số liệu về việc áp dụng passkey nào tôi nên nhắm tới và theo dõi sau khi ra mắt?

Sự áp dụng mạnh mẽ có nghĩa là tỷ lệ tạo passkey trên 60% người dùng đủ điều kiện và tỷ lệ đăng nhập bằng passkey trên 40% của tất cả các lần đăng nhập. Các tỷ lệ tạo dưới 10% và đăng nhập dưới 5% sau ba tháng là tín hiệu cho thấy một đợt triển khai thất bại. Việc đo lường điều này đòi hỏi một cơ sở hạ tầng chuyên dụng theo dõi tỷ lệ tạo, tỷ lệ đăng nhập thành công, tỷ lệ dự phòng và tỷ lệ từ bỏ được phân chia theo tổ hợp thiết bị và hệ điều hành.

### Tôi có nên xây dựng passkey trực tiếp trong ứng dụng di động (native) hay sử dụng WebView không?

Việc triển khai Native cung cấp UX tốt nhất trong phân khúc nhưng yêu cầu cơ sở mã iOS và Android riêng biệt với việc xử lý API cụ thể cho từng nền tảng và các đường ống (pipelines) QA độc lập. Phương pháp tiếp cận WebView chia sẻ logic web nhưng gây ra sự không nhất quán trong việc hỗ trợ passkey tùy thuộc vào loại WebView. Chỉ riêng trên iOS, sự lựa chọn giữa WKWebView, SFSafariViewController và ASWebAuthenticationSession đều mang các đặc điểm hỗ trợ passkey khác nhau cần được đánh giá trước khi cam kết theo một kiến trúc nào.

### Tại sao việc khôi phục tài khoản passkey lại khó hơn vẻ bề ngoài và cách tiếp cận đúng đắn là gì?

Việc khôi phục đơn giản hóa như thiết lập lại dựa trên email sẽ đưa các kênh dễ bị lừa đảo trở lại, trong khi việc khôi phục quá nghiêm ngặt như yêu cầu khóa bảo mật phần cứng bắt buộc sẽ tạo ra sự từ bỏ. Cách tiếp cận được đề xuất là khôi phục theo nhiều lớp: passkey được đồng bộ hóa là chiến lược chính, xác thực đa thiết bị bằng mã QR là lớp thứ hai, xác minh danh tính tự động với tính năng kiểm tra sự sống (liveness checks) là lớp thứ ba và thông tin xác thực có thể xác minh kỹ thuật số (digital verifiable credentials) là lớp thứ tư. Việc chọn những lớp nào để thực hiện tùy thuộc vào mô hình mối đe dọa, cơ sở người dùng và yêu cầu pháp lý của bạn.