Khắc phục sự cố passkey: Giải pháp cho các vấn đề & lỗi passkey

1. Giới thiệu#

Passkey hiện được hỗ trợ bởi 20% trong số 100 trang web hàng đầu thế giới và 53% người tiêu dùng toàn cầu đã bật passkey trên ít nhất một tài khoản, theo FIDO Alliance Authentication Barometer 2024. Amazon, WhatsApp, Coinbase, TikTok, Facebook, LinkedIn và X/Twitter đều đã triển khai hỗ trợ từ năm 2023.

Đặc tả W3C WebAuthn Level 3 định nghĩa một loạt các ngoại lệ DOM, nhưng các trình duyệt cố tình gộp hầu hết các lỗi thất bại (người dùng hủy, hết thời gian chờ, authenticator không đủ điều kiện) vào lỗi chung NotAllowedError để tránh rò rỉ quyền riêng tư, theo W3C Privacy Considerations. Nhiều bên phụ thuộc (relying party) cũng tự định nghĩa các thông báo lỗi của riêng họ, vì chưa có nhiều thực tiễn tốt nhất được chứng minh ngoài Hướng dẫn UX của FIDO Alliance. Hướng dẫn này sẽ ánh xạ các cách diễn đạt phổ biến nhất đối với người tiêu dùng tới một nguyên nhân rõ ràng và một giải pháp thực tế, với ảnh chụp màn hình từ cả bản phát hành gốc và các bản dựng iOS, Android mới nhất.

Nếu "passkey google không hoạt động" trên thiết bị của bạn, bước kiểm tra đầu tiên là xem trình duyệt, hệ điều hành và Google Play services có đang ở phiên bản hiện tại hay không, vì hầu hết các lỗi hồi quy đều được khắc phục trong một hoặc hai bản phát hành.

2. Passkey hoạt động như thế nào?#

Passkey là thông tin xác thực không cần mật khẩu dựa trên WebAuthn API và đặc tả CTAP 2.2 nền tảng từ FIDO Alliance. W3C đã chuẩn hóa WebAuthn Level 1 vào tháng 3 năm 2019, Level 2 vào tháng 4 năm 2021 và Level 3 vào năm 2024. Việc áp dụng đạt khoảng 1 tỷ thông tin xác thực được đăng ký trên các hệ sinh thái lớn vào quý 4 năm 2024, theo FIDO Alliance Authenticate 2024.

Thiết bị tạo ra một cặp khóa duy nhất khi đăng ký. Chỉ có public key được gửi đến bên phụ thuộc, trong khi private key nằm lại bên trong secure enclave, TPM hoặc TEE. Khi đăng nhập, máy chủ gửi một thử thách (challenge), thiết bị mở khóa private key bằng Face ID, Touch ID hoặc Windows Hello, ký thử thách và trả về chữ ký. Bên phụ thuộc xác minh nó bằng public key.

Vì private key không bao giờ rời khỏi thiết bị, các cuộc tấn công phishing và sử dụng lại mật khẩu sẽ không còn tác dụng. Từ góc độ người dùng, toàn bộ quy trình chỉ là một lời nhắc sinh trắc học duy nhất.

3. Các yêu cầu về passkey#

3.1 iOS hoặc macOS#

Đã bật iCloud Keychain:

iCloud Keychain là vị trí lưu trữ cho thông tin xác thực trên các thiết bị Apple và có sẵn trên iOS 16, iPadOS 16, macOS Ventura 13 trở lên. Apple báo cáo có khoảng 2,2 tỷ thiết bị hoạt động vào đầu năm 2024, trong đó hơn 90% chạy iOS 16 trở lên, theo bảng điều khiển nhà phát triển của Apple. Để bật iCloud Keychain, hãy điều hướng đến cài đặt thiết bị của bạn, chọn Apple ID của bạn, đi đến iCloud và sau đó bật iCloud Keychain (đọc thêm tại đây). Theo tài liệu dành cho nhà phát triển của Apple, các tài khoản iCloud có bật Keychain buộc phải sử dụng MFA.

Yêu cầu iOS 16 hoặc macOS Ventura:

iOS 16 ra mắt vào ngày 12 tháng 9 năm 2022 và macOS Ventura 13 ra mắt vào ngày 24 tháng 10 năm 2022. Trên iOS 18, nơi lưu trữ đã chuyển sang một ứng dụng Passwords chuyên dụng, đó là lý do tại sao một số lời nhắc hiện hiển thị "Passwords" thay vì "iCloud Keychain". Theo hỗ trợ của Apple, người dùng trên các phiên bản hệ điều hành cũ hoàn toàn không thể tạo hoặc sử dụng passkey.

3.2 Windows#

Thiết lập Windows Hello:

Windows Hello là bắt buộc để tạo hoặc sử dụng passkey trên các thiết bị Windows 10 và Windows 11. Theo tài liệu passkey Windows của Microsoft, Windows 11 bản dựng 22631 (tháng 11 năm 2024) đã cung cấp giao diện người dùng passkey gốc và Windows 11 25H2 (tháng 11 năm 2025) đã bổ sung hỗ trợ cho các trình quản lý passkey của bên thứ ba như 1Password và Bitwarden. Windows Hello chấp nhận dấu vân tay, quét khuôn mặt hoặc mã PIN 6 chữ số. Định cấu hình tính năng này trong Cài đặt > Tài khoản > Tùy chọn đăng nhập (đọc thêm tại đây).

3.3 Android#

Android phiên bản 9 trở lên:

Android 9 (Pie) ra mắt vào ngày 6 tháng 8 năm 2018 và là mức tối thiểu cho Credential Manager API. Theo bảng điều khiển phân phối Android, Android 9 trở lên chạy trên khoảng 95% thiết bị Android đang hoạt động vào năm 2026. Các bản dựng cũ hơn hoàn toàn không thể sử dụng passkey vì chúng thiếu StrongBox Keymaster và Credential Manager.

Cập nhật Google Play Services:

Cần có Google Play services phiên bản 23.40 trở lên cho Credential Manager. Google Play services cập nhật khoảng 4 đến 6 tuần một lần và hầu hết các sự cố "passkey google không hoạt động" (google passkey not working) đều bắt nguồn từ một phiên bản cũ. Cập nhật Google Play services và hệ thống WebView trong Cài đặt > Ứng dụng và thử lại.

Trên tất cả các nền tảng, hãy giữ trình duyệt ở bản dựng hiện tại. Safari, Chrome và Edge phát hành các bản cập nhật ổn định khoảng hàng tuần và hầu hết các lỗi hồi quy đều được khắc phục trong một hoặc hai bản phát hành.

4. Các lỗi passkey phổ biến, nguyên nhân và cách khắc phục#

Chúng tôi theo dõi khoảng 15 mô hình lỗi lặp lại trên các máy khách iOS, Android và Windows, cùng nhau chiếm phần lớn số lượng phiếu hỗ trợ người tiêu dùng được quan sát thấy trên các bên phụ thuộc lớn. 6 phần tiếp theo nhóm các lỗi đó theo nguyên nhân gốc rễ: lỗi iCloud Keychain và ứng dụng Apple Passwords, lỗi không có thông tin xác thực khả dụng, lỗi mã QR và luồng đa thiết bị, các sự cố cụ thể của Windows, các sự cố cụ thể của Android và nhóm lỗi WebAuthn hoặc trình duyệt chung.

Mỗi mục bao gồm ảnh chụp màn hình từ bản phát hành gốc cũng như các bản dựng iOS mới nhất và bản dựng Android Credential Manager, nguyên nhân có khả năng nhất và một giải pháp đã mang lại hiệu quả cho những người khác. Khi hữu ích, các mục sẽ tham chiếu đến đặc tả W3C WebAuthn Level 3, các đặc tả của FIDO Alliance hoặc tài liệu nền tảng liên quan từ Apple, Microsoft và Android Credential Manager.

5. Lỗi iCloud Keychain và ứng dụng Apple Passwords#

Nhóm này bao gồm hai lỗi mà các thiết bị Apple hiển thị khi iCloud Keychain không được thiết lập chính xác. Cả hai đều được hệ thống tự hiển thị, không phải bởi bên phụ thuộc. iCloud Keychain là yêu cầu bắt buộc đối với passkey trên iOS 16, iPadOS 16 hoặc macOS Ventura 13 trở lên, theo tài liệu dành cho nhà phát triển của Apple. Trên iOS 18, nơi lưu trữ đã chuyển sang ứng dụng Passwords mới, đó là lý do tại sao cách diễn đạt đã thay đổi.

Thông báo lỗi: Để lưu passkey, bạn cần bật iCloud Keychain. Bạn có thể bật Keychain trong bảng điều khiển Apple ID của Cài đặt Hệ thống#

Trên iOS mới nhất, cách diễn đạt là "Để sử dụng passkey, bạn cần bật iCloud Keychain" (To use passkeys, you need to enable iCloud Keychain) và đường dẫn đã được đổi tên thành Cài đặt > Tài khoản Apple > iCloud > Passwords và Keychain:

• Nguyên nhân: iCloud Keychain, vị trí lưu trữ thông tin xác thực trên các thiết bị Apple, chưa được bật.
• Giải pháp: Bật iCloud Keychain trong bảng điều khiển Apple ID của Cài đặt Hệ thống (hoặc Cài đặt > Tài khoản Apple > iCloud > Passwords và Keychain trên iOS 18). Đảm bảo rằng nó đồng bộ trên các thiết bị của bạn, nếu không thông tin xác thực sẽ chỉ tồn tại cục bộ.

Thông báo lỗi: Không có passkey phù hợp / Không có passkey phù hợp nào được lưu trong iCloud Keychain của bạn#

Trên iOS mới nhất, lời nhắc hiện được gắn thương hiệu với ứng dụng Passwords mới và có nội dung "Không có passkey phù hợp nào được lưu trong Passwords cho..." (There are no matching passkeys saved in Passwords for ...):

• Nguyên nhân: Người dùng cố đăng nhập bằng thông tin xác thực không được lưu trữ trong iCloud Keychain trên thiết bị hiện tại, hoặc tính năng đồng bộ hóa giữa các thiết bị bị lỗi.
• Giải pháp: Xác nhận rằng iCloud Keychain được bật trên mọi thiết bị Apple sử dụng cùng một Apple ID. Nếu thông tin xác thực tồn tại trên một iPhone hoặc máy Mac khác nhưng không có trên thiết bị hiện tại, hãy buộc đồng bộ hóa Keychain bằng cách tắt và bật lại iCloud Keychain, sau đó thử đăng nhập lại. Nếu hoàn toàn không có thông tin xác thực nào, hãy đăng ký một thông tin xác thực mới từ cài đặt tài khoản của bên phụ thuộc.

6. Lỗi không có passkey khả dụng và passkey đã tồn tại#

Các lỗi này xuất hiện khi thông tin xác thực mà người dùng mong đợi không có trên thiết bị hiện tại, đã được đăng ký hoặc đã bị xóa ở một bên và bên kia thì không. Thuộc tính WebAuthn AllowCredentials và excludeCredentials điều khiển hầu hết hành vi này ở phía máy chủ.

Thông báo lỗi: Không có passkey nào khả dụng. Không có bất kỳ passkey nào cho Bên Phụ Thuộc trên thiết bị này#

Trên Android, lỗi tương tự được hiển thị bởi Google Play services với nội dung "Không có passkey nào khả dụng. Không có bất kỳ passkey nào cho <bên phụ thuộc> trên thiết bị này" (No passkeys available. There aren't any passkeys for <relying party> on this device) và tùy chọn dự phòng "Sử dụng thiết bị khác":

• Nguyên nhân: Không có thông tin xác thực phù hợp nào trên thiết bị hiện tại và máy chủ WebAuthn không cho phép bất kỳ authenticator đa nền tảng nào. Thông báo lỗi tương tự cũng xuất hiện khi người dùng đã xóa thông tin xác thực cục bộ nhưng máy chủ vẫn mong đợi nó.
• Giải pháp: Xác minh xem có thông tin xác thực trên thiết bị hay không. Nếu nó đã bị xóa trong cài đặt iCloud Keychain hoặc Google Password Manager, hãy cũng xóa nó ở phía máy chủ trong cài đặt tài khoản của bên phụ thuộc. Nếu không, máy chủ sẽ liên tục yêu cầu thông tin xác thực bị thiếu và lỗi sẽ liên tục xuất hiện.

Thông báo lỗi: Passkey đã tồn tại (hoặc thông báo lỗi tương tự như được định nghĩa bởi bên phụ thuộc)#

• Nguyên nhân: Đang cố gắng đăng ký mới trên một thiết bị đã có thông tin xác thực cho cùng một tài khoản. Nhiều bên phụ thuộc chỉ cho phép một thông tin xác thực cho mỗi thiết bị hoặc hệ sinh thái (ví dụ: iCloud Keychain đã đồng bộ hóa hoặc 1Password) bằng cách cài đặt excludeCredentials trên máy chủ WebAuthn.
• Giải pháp: Sử dụng thông tin xác thực hiện có hoặc đăng ký một thông tin xác thực mới từ một thiết bị khác. Hoặc, xóa thông tin xác thực cũ trong cài đặt tài khoản của bên phụ thuộc, sau đó đăng ký một thông tin xác thực mới.

Thông báo lỗi: Chúng tôi không thể tìm thấy passkey phù hợp (hoặc thông báo tương tự từ bên phụ thuộc)#

• Nguyên nhân: Một thông tin xác thực đã bị xóa thủ công, ở phía client hoặc phía máy chủ. Ngay cả khi private key cục bộ vẫn tồn tại, sự vắng mặt của public key phù hợp trên máy chủ cũng sẽ kích hoạt lỗi này.
• Giải pháp: Đăng nhập từ một thiết bị khác hoặc sử dụng phương thức xác thực dự phòng. Sau đó tạo một thông tin xác thực mới từ cài đặt tài khoản, điều này sẽ thiết lập lại cặp khóa máy khách-máy chủ.

7. Mã QR và các lỗi đăng nhập đa thiết bị#

Luồng mã QR sử dụng giao thức truyền tải lai (hybrid transport) FIDO (còn gọi là CTAP 2.2 hybrid). Theo đặc tả FIDO CTAP, hai thiết bị trao đổi bí mật một lần qua mã QR và sau đó giao tiếp qua Bluetooth Low Energy ở khoảng cách tối đa khoảng 3 mét. Cả Bluetooth và khoảng cách gần đều là bắt buộc, nếu không luồng sẽ bị lỗi âm thầm.

Thông báo lỗi: Tôi đang thấy mã QR#

Trên iOS mới nhất, bảng QR đa thiết bị hiện ghi "Quét mã QR. Quét mã QR này bằng thiết bị tương thích để đăng nhập vào..." (Scan QR Code. Scan this QR code with a compatible device to sign in to ...):

Trên Android, Credential Manager hiển thị luồng tương tự như "Không có phương thức đăng nhập nào khả dụng" (No available sign-in) với tùy chọn Hiển thị mã QR (Show QR code) và giải pháp dự phòng Mở Google Password Manager (Open Google Password Manager):

• Nguyên nhân: Thông tin xác thực được gắn với một tài khoản và nền tảng cụ thể (thiết bị hoặc tài khoản nền tảng được đồng bộ hóa trên đám mây như iCloud Keychain). Việc thấy mã QR có nghĩa là không có thông tin xác thực nào trên thiết bị hiện tại, ngay cả khi người dùng đã đăng ký trước đó trên iOS hoặc Android. Một nguyên nhân phổ biến khác là máy chủ hạn chế các thông tin xác thực mà nó chấp nhận thông qua thuộc tính WebAuthn AllowCredentials và các thông tin xác thực cục bộ hiện có không phù hợp.
• Giải pháp: Nếu thiết bị ban đầu có camera, hãy quét mã QR để đăng nhập qua giao thức truyền tải lai. Nếu không, hãy sử dụng phương pháp dự phòng, đăng nhập và sau đó đăng ký một thông tin xác thực mới cho thiết bị hiện tại trong cài đặt tài khoản của bên phụ thuộc.

Thông báo lỗi: Yêu cầu bật Bluetooth để đăng nhập passkey qua nhiều thiết bị#

• Nguyên nhân: Giao thức truyền tải lai yêu cầu Bluetooth Low Energy giữa hai thiết bị. Nếu Bluetooth bị tắt trên PC hoặc trên điện thoại, luồng sẽ gặp lỗi âm thầm với các thông báo chung chung "Đã xảy ra lỗi" (Something went wrong) hoặc "Chúng tôi không thể đăng nhập cho bạn" (We couldn't sign you in).
• Giải pháp: Bật Bluetooth trên cả hai thiết bị và giữ chúng trong phạm vi khoảng 3 mét với nhau, sau đó thử lại luồng mã QR. Nếu không thể bật Bluetooth (ví dụ: chính sách doanh nghiệp hoặc phần cứng cũ), hãy sử dụng phương thức đăng nhập dự phòng và sau đó đăng ký thông tin xác thực cục bộ trên thiết bị để các lần đăng nhập trong tương lai không còn phụ thuộc vào giao thức truyền tải lai.

8. Các lỗi dành riêng cho Windows#

Các bản dựng Windows đã xuất xưởng một số lỗi hồi quy liên quan đến passkey trong vòng 18 tháng qua. Theo tài liệu passkey Windows của Microsoft, bản dựng 22631 (tháng 11 năm 2024) đã thêm giao diện người dùng passkey gốc và Windows 11 25H2 (tháng 11 năm 2025) đã bổ sung hỗ trợ trình quản lý passkey của bên thứ ba. Cả hai thay đổi này đều đặt lại một số trạng thái của Windows Hello.

Thông báo lỗi: Cắm khóa bảo mật của bạn vào cổng USB#

• Nguyên nhân: Cần có khóa bảo mật phần cứng (ví dụ: YubiKey) vì thiết bị không có TPM hoặc Windows Hello bị vô hiệu hóa. Lời nhắc tương tự cũng xuất hiện trên các máy tính không có Bluetooth không thể sử dụng giao thức truyền tải lai và không có thông tin xác thực cục bộ.
• Giải pháp: Cắm khóa bảo mật (ví dụ: YubiKey) vào cổng USB. Để bỏ qua khóa phần cứng, hãy bật Windows Hello trước rồi tạo thông tin xác thực Windows Hello trước lần đăng nhập tiếp theo.

Thông báo lỗi: Passkey tài khoản Microsoft liên tục bị lỗi sau bản cập nhật Windows gần đây#

• Nguyên nhân: Một số bản dựng nội bộ (Insider) và bản phát hành Windows 11 đã làm hỏng các luồng đăng nhập tài khoản Microsoft, hiển thị dưới dạng "Đã xảy ra lỗi" (Something went wrong), "Chúng tôi không thể đăng nhập cho bạn" (We couldn't sign you in) hoặc lỗi âm thầm trong quá trình tạo. Nguyên nhân gốc rễ thường là do trạng thái Windows Hello bị hỏng hoặc tài khoản Microsoft ban đầu được cấu hình với thiết lập cũ hơn.
• Giải pháp: Đăng nhập bằng mật khẩu cộng với MFA, xóa thông tin xác thực bị hỏng trong cài đặt bảo mật tài khoản Microsoft và tạo một thông tin mới. Trên tài khoản cục bộ, hãy sao lưu và xóa thư mục NGC của Windows Hello (C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc), sau đó đăng ký lại Windows Hello. Coi việc đăng nhập bằng tài khoản Microsoft trên Windows là nỗ lực tốt nhất và luôn giữ ít nhất một tùy chọn MFA không phải passkey đang hoạt động.

9. Các lỗi dành riêng cho Android#

Android Credential Manager API yêu cầu Google Play services 23.40 trở lên và dựa vào màn hình khóa an toàn để xác minh người dùng, theo tài liệu Android Credential Manager. Các thiết bị không có khóa màn hình hoàn toàn không thể đăng ký hoặc sử dụng thông tin xác thực.

Thông báo lỗi: Không cung cấp passkey (Passkeys not offered)#

• Nguyên nhân: Thiết bị Android không kích hoạt khóa màn hình. Android yêu cầu mã PIN, hình mở khóa, mật khẩu hoặc khóa sinh trắc học để kiểm soát quyền truy cập vào thông tin xác thực, vì vậy nếu không có khóa, tùy chọn này sẽ bị ẩn.
• Giải pháp: Bật khóa màn hình trong Cài đặt > Bảo mật trên thiết bị, sau đó thử lại. Trên các bản dựng Android cũ hơn, cũng xác nhận rằng Google Play services đã được cập nhật.

10. Các lỗi WebAuthn và Trình duyệt chung#

Các lỗi này đến trực tiếp từ trình duyệt hoặc lớp WebAuthn. Chúng cố tình mang tính chung chung để bảo vệ quyền riêng tư của người dùng. Các trình duyệt tiết lộ từ 10 đến 14 ngoại lệ DOM khác nhau trong quá trình xác thực theo đặc tả W3C và lỗi phổ biến nhất (NotAllowedError) bao gồm việc hủy bỏ, hết thời gian chờ và sự từ chối nền tảng thầm lặng vào một nhóm chung.

Thông báo lỗi: Không thể tạo passkey của bạn / Lỗi khi tạo Passkey / Lỗi trong khi tạo passkey#

• Nguyên nhân: Có sự cố trong ứng dụng của bên phụ thuộc, lỗi máy chủ tạm thời hoặc cài đặt thiết bị không tương thích (ví dụ: hệ điều hành cũ không hỗ trợ WebAuthn).
• Giải pháp: Khởi động lại ứng dụng hoặc thiết bị và thử lại. Nếu sự cố vẫn tiếp diễn, hãy cập nhật hệ điều hành và trình duyệt. Nếu chỉ một bên phụ thuộc bị ảnh hưởng, sự cố nằm ở phía máy chủ và việc thử lại sau vài phút thường sẽ giải quyết được.

Thông báo lỗi: Passkey không khả dụng trên thiết bị hoặc trình duyệt này#

• Nguyên nhân: Trình duyệt hoặc hệ điều hành không hỗ trợ WebAuthn hoặc bên phụ thuộc (ví dụ: PayPal) chặn sự kết hợp hiện tại. Các ví dụ phổ biến là các bản dựng trình duyệt cũ, các trình duyệt ngách không hỗ trợ WebAuthn hoặc các thiết bị do doanh nghiệp quản lý với các chính sách hạn chế.
• Giải pháp: Cập nhật trình duyệt và hệ điều hành. Nếu thiết bị về cơ bản không tương thích, hãy chuyển sang một thiết bị được hỗ trợ (Safari trên iOS 16+, Chrome trên Android 9+, Edge hoặc Chrome trên Windows 10+).

Thông báo lỗi: Đã xảy ra lỗi. Có sự cố khi đăng nhập bằng passkey của bạn.#

• Nguyên nhân: Đã chọn sai thông tin xác thực, trục trặc mạng tạm thời giữa thiết bị và máy chủ hoặc sự cố trong lớp WebAuthn của trình duyệt.
• Giải pháp: Xác nhận rằng thông tin xác thực phù hợp đã được chọn từ lời nhắc. Thử lại sau một thời gian chờ ngắn. Nếu sự cố vẫn tiếp diễn, hãy kiểm tra mạng và đặt lại thông tin xác thực bằng cách đăng ký lại từ cài đặt tài khoản.

Thông báo lỗi: Đã xảy ra lỗi. Yêu cầu đã hết thời gian chờ.#

• Nguyên nhân: Máy chủ mất quá nhiều thời gian để phản hồi, thường do mạng không ổn định hoặc tải cao. Thời gian chờ WebAuthn mặc định trong Chrome là 60 giây, với tối đa 600 giây được xác định bởi đặc tả W3C.
• Giải pháp: Thử lại trên một kết nối ổn định. Nếu kết nối bình thường, vấn đề là ở phía máy chủ và việc thử lại sau vài phút thường sẽ xóa lỗi. Các bên phụ thuộc có thể nâng thời gian chờ lên đến giới hạn W3C nếu backend của họ thường xuyên vượt quá mặc định.

Thông báo lỗi: NotAllowedError. Hoạt động bị hết thời gian chờ hoặc không được phép#

• Nguyên nhân: Lỗi WebAuthn chung được trình duyệt trả về khi một quá trình xác thực không hoàn tất. Điều này có thể có nghĩa là người dùng đã hủy, quá thời gian chờ, một nguồn (origin) bị chặn, thiếu một hành động từ phía người dùng hoặc thiết bị xác thực nền tảng đã từ chối yêu cầu. Trình duyệt che giấu nguyên nhân chính xác vì lý do quyền riêng tư.
• Giải pháp: Tăng thời gian chờ WebAuthn ở phía bên phụ thuộc và đảm bảo cuộc gọi được kích hoạt bằng một hành động trực tiếp của người dùng như nhấp vào nút. Xác minh rằng ID của bên phụ thuộc khớp với origin, người dùng có một authenticator có thể sử dụng và không có tiện ích mở rộng trình duyệt nào chặn cuộc gọi. Người dùng cuối thường có thể khắc phục sự cố này bằng cách mở khóa thiết bị, xác nhận lời nhắc sinh trắc học hoặc mã PIN và thử lại.

11. Kết luận#

Passkey loại bỏ loại lỗ hổng bảo mật liên quan đến mật khẩu bằng cách thay thế các bí mật dùng chung (shared secrets) bằng mã hóa khóa công khai (public key cryptography). Việc triển khai trong thế giới thực báo cáo việc đăng nhập nhanh hơn 4 đến 6 lần so với việc dùng mật khẩu cộng với OTP, với Báo cáo Điều tra Vi phạm Dữ liệu 2024 của Verizon quy kết 68% các vụ vi phạm là do các yếu tố con người không có ác ý bao gồm lạm dụng thông tin xác thực. Cắt giảm bề mặt tấn công đó là toàn bộ mục đích.

Trong thực tế, 15 lỗi trên chiếm phần lớn số phiếu hỗ trợ người tiêu dùng mà chúng tôi gặp trong cộng đồng passkey, và việc khắc phục sự cố đúng cách là điều cần thiết để mở rộng việc áp dụng passkey. Làm theo các phương pháp hay nhất về việc tạo và thực hành đăng nhập giúp giảm đáng kể tỷ lệ lỗi. Để cập nhật về xử lý lỗi và thông tin triển khai, hãy đăng ký nhận Substack passkey hoặc tham gia cộng đồng trên Slack.

Về Corbado

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

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

Tại sao tôi được yêu cầu cắm khóa bảo mật thay vì sử dụng passkey của mình?#

Lời nhắc này xuất hiện khi Windows Hello bị vô hiệu hóa hoặc không có TPM, khiến hệ thống chuyển sang xác thực bằng khóa bảo mật phần cứng. Việc bật Windows Hello trong cài đặt đăng nhập của thiết bị sẽ giải quyết vấn đề này, nhưng trước tiên bạn phải tạo passkey Windows Hello trước khi sử dụng nó để đăng nhập.

Làm cách nào để sửa lỗi 'không thể tạo passkey của bạn'?#

Lỗi này thường do trục trặc ứng dụng, sự cố máy chủ tạm thời hoặc cài đặt thiết bị không tương thích. Việc khởi động lại ứng dụng hoặc thiết bị và kiểm tra các bản cập nhật hệ điều hành, ứng dụng thường sẽ giải quyết được. Nếu sự cố xuất hiện từ phía máy chủ, bạn nên chờ và thử lại sau.

Tại sao xác thực passkey liên tục bị hết thời gian chờ?#

Lỗi hết thời gian chờ xảy ra khi máy chủ mất quá nhiều thời gian để phản hồi, thường do mạng không ổn định hoặc tải máy chủ cao. Kiểm tra kết nối internet là bước đầu tiên. Nếu kết nối ổn định, vấn đề có thể nằm ở phía máy chủ và việc thử lại sau một thời gian ngắn thường sẽ giải quyết được.

Điều gì xảy ra nếu tôi xóa passkey trên thiết bị của mình nhưng không xóa trong cài đặt tài khoản?#

Việc xóa passkey ở phía client, chẳng hạn như từ iCloud Keychain hoặc Google Password Manager, mà không xóa nó trong cài đặt tài khoản của bên phụ thuộc (relying party) sẽ gây ra lỗi 'không có passkey phù hợp' (no matching passkey). Máy chủ vẫn giữ public key và mong đợi thông tin xác thực, vì vậy cần phải xóa cả ở phía client và máy chủ trước khi đăng ký passkey mới.

NotAllowedError có nghĩa là gì khi sử dụng passkey?#

NotAllowedError là một lỗi WebAuthn chung mà các trình duyệt trả về khi quá trình xác thực passkey không hoàn tất. Nó có thể do người dùng hủy, hết thời gian chờ, thiếu thao tác của người dùng, origin bị chặn hoặc authenticator của nền tảng từ chối yêu cầu. Trình duyệt ẩn nguyên nhân chính xác vì lý do quyền riêng tư. Việc thử lại luồng sau một thao tác trực tiếp của người dùng và xác nhận sinh trắc học hoặc mã PIN thường sẽ giải quyết được.

Tại sao iOS hiển thị 'Không có passkey nào khớp được lưu trong Passwords'?#

Trên iOS 18 trở lên, vị trí lưu trữ cho passkey đã chuyển vào ứng dụng Passwords mới, vì vậy cách diễn đạt đã đổi từ "iCloud Keychain" thành "Passwords". Lỗi này có nghĩa là thông tin xác thực bị thiếu trên thiết bị này hoặc đồng bộ hóa iCloud không hoạt động. Hãy xác nhận iCloud Keychain được bật trên mọi thiết bị Apple sử dụng cùng một Apple ID, buộc đồng bộ hóa bằng cách tắt và bật lại iCloud Keychain, sau đó thử đăng nhập lại. Nếu hoàn toàn không có thông tin xác thực nào, hãy đăng ký một thông tin xác thực mới từ cài đặt tài khoản của bên phụ thuộc.

Tại sao Android hiển thị 'Không có phương thức đăng nhập nào khả dụng cho bên phụ thuộc'?#

Android Credential Manager hiển thị lời nhắc này khi không có thông tin xác thực nào phù hợp được lưu trữ cho bên phụ thuộc được yêu cầu trên thiết bị hiện tại. Nó thường cung cấp tùy chọn "Hiển thị mã QR" (Show QR code) để sử dụng passkey từ một thiết bị khác thông qua giao thức truyền tải lai FIDO (hybrid transport), cộng với một tùy chọn dự phòng để mở Google Password Manager. Bạn có thể quét mã QR bằng điện thoại đã có sẵn thông tin xác thực, đăng nhập bằng phương thức dự phòng hoặc đăng ký một thông tin xác thực mới trên thiết bị hiện tại từ cài đặt tài khoản của bên phụ thuộc.

Luồng đăng nhập passkey qua mã QR trên nhiều thiết bị hoạt động như thế nào?#

Luồng đăng nhập trên nhiều thiết bị là giao thức truyền tải lai FIDO (hybrid transport) được định nghĩa trong CTAP 2.2. Trình duyệt trên máy tính hiển thị một mã QR chứa bí mật một lần (one-time secret). Điện thoại dùng camera để quét nó và sau đó kết nối lại qua Bluetooth Low Energy ở khoảng cách tối đa khoảng 3 mét. Sau khi người dùng xác minh trên điện thoại, quá trình WebAuthn sẽ hoàn tất trên máy tính. Cả Bluetooth và khoảng cách gần đều bắt buộc, nếu không, luồng đăng nhập sẽ thất bại âm thầm với các thông báo chung chung "Đã xảy ra lỗi" hoặc "Chúng tôi không thể đăng nhập cho bạn".