Hướng dẫn toàn diện về lỗi WebAuthn trong môi trường Production (2026)

Trong môi trường production, các lỗi WebAuthn thường gây nhầm lẫn vì các trình duyệt hiển thị một tập hợp nhỏ các tên DOMException (như NotAllowedError) có thể đại diện cho nhiều nguyên nhân cơ bản. Hơn thế nữa, phần lớn các "lỗi" - thường trên 95% trong các đợt triển khai quy mô lớn được tối ưu hóa - thực chất là hành vi dự kiến (người dùng đã hủy lời nhắc passkey của hệ điều hành).

Thử nghiệm các luồng passkey trong Passkeys Debugger.

Thử miễn phí

Nếu bạn muốn có các định nghĩa chuẩn xác cho những tên này, hãy bắt đầu với MDN DOMException. Để biết các điều kiện cụ thể của WebAuthn dẫn đến những ngoại lệ này (và những gì trình duyệt bắt buộc phải thực thi), hãy xem Thông số kỹ thuật Web Authentication của W3C.

Nếu bạn coi mọi lỗi là "bug", bạn sẽ thực hiện sai những việc sau:

• bạn sẽ làm bẩn số liệu lỗi của mình bằng các lượt hủy thông thường
• bạn sẽ bỏ lỡ các lỗi hồi quy thực sự ẩn giấu bên trong vô số NotAllowedError
• bạn sẽ tung ra giao diện người dùng (UI) gây bối rối cho người dùng thay vì giúp họ khắc phục

Trong bài viết này, chúng tôi trả lời:

• Các tên lỗi WebAuthn phổ biến nhất thường có ý nghĩa gì trong lưu lượng truy cập thực tế?
• Làm thế nào để bạn phân biệt NotAllowedError thành các nhóm có thể xử lý (hủy bỏ, quá thời gian, tình trạng sẵn có)?
• Tại sao cùng một lỗi lại có ý nghĩa khác nhau tùy thuộc vào hoạt động (đăng nhập conditional UI, đăng nhập modal, tạo passkey, conditional create)?
• Ngữ cảnh tối thiểu nào bạn nên nắm bắt để "nó thất bại" trở thành một vấn đề có thể tái hiện?

Nếu bạn chỉ cần một sơ đồ phân loại nhanh để gỡ rối quá trình sửa lỗi, hãy bắt đầu với bảng này. Nó tập trung vào những gì các nhóm thực sự thấy trong dashboard và các ticket hỗ trợ.

Một điều dễ bỏ sót: cùng một error.name có thể mang ý nghĩa rất khác nhau tùy thuộc vào loại hoạt động. Hãy luôn lưu ý ngữ cảnh hoạt động khi bạn đọc các phần bên dưới. Trong thực tế, các lỗi tạo passkey (đăng ký) thường nhiều hơn lỗi đăng nhập rất nhiều - bảng trên áp dụng cho cả hai, nhưng phần tạo mới là nơi tập trung khối lượng lớn.

Tiếp theo, chúng ta sẽ đi sâu hơn vào NotAllowedError vì đây là lỗi bạn sẽ thấy nhiều nhất và là lỗi mà các nhóm thường hiểu sai nhất.

NotAllowedError thường giống như "passkeys thất bại", nhưng nó thường là nền tảng đang báo cho bạn biết người dùng đã không hoàn thành UI của hệ điều hành. Chìa khóa ở đây là chia nó thành các nhóm mà bạn có thể xử lý.

Những gì bạn sẽ thấy trong bảng điều khiển trình duyệt:

Tất cả những lỗi này hiển thị dưới dạng error.name === "NotAllowedError". error.message khác nhau tùy theo công cụ trình duyệt và nguyên nhân cơ bản, nhưng kết quả đều giống nhau: nghi thức không hoàn tất.

Điều này áp dụng cho cả đăng nhập và tạo passkey. Trong quá trình đăng nhập (conditional UI, modal có hoặc không có allowList), NotAllowedError thường có nghĩa là người dùng đã không hoàn thành nghi thức. Trong quá trình tạo passkey, cùng một lỗi hiển thị vì nhiều lý do khác nhau: người dùng đã đóng hộp thoại tạo, conditional create không hoạt động, hoặc trang bị mất tiêu điểm trong quá trình thao tác nối thêm được kích hoạt tự động. Loại hoạt động thay đổi ý nghĩa của lỗi và những gì bạn nên làm với nó.

Thời gian thường là một tín hiệu bị đánh giá thấp. Một lỗi xảy ra dưới 1 giây sau khi nhấp chuột thường là từ chối ngay lập tức (môi trường không thể làm được, tài liệu không được chú ý, thiếu khả năng). Một lỗi xảy ra sau vài giây là do người dùng hủy bỏ (họ thấy hộp thoại và quyết định không tiếp tục). Một lỗi sau hơn 30 giây là đã quá thời gian. Trên các nền tảng native, thời gian đặc biệt quan trọng: thời gian khứ hồi của authenticator, lời nhắc sinh trắc học và quá trình chuyển giao ứng dụng quản lý mật khẩu đều có khoảng thời gian đặc trưng giúp bạn phân biệt "không hiệu quả" với "người dùng đã rời đi". Bạn vẫn không thể dễ dàng phân biệt được liệu một passkey có tồn tại hay không.

Bạn không cần một tín hiệu hoàn hảo. Bạn cần đủ ngữ cảnh để tránh việc đối xử với mọi lỗi NotAllowedError theo cùng một cách. iOS/Safari nhận được sự chú ý đặc biệt ở bên dưới vì nó có những hạn chế riêng (yêu cầu kích hoạt người dùng ở các phiên bản trước), nhưng về số lượng lỗi thô, các trình duyệt Windows và Chromium thường tạo ra nhiều lỗi NotAllowedError hơn bất kỳ nền tảng nào khác. Những tín hiệu này thường giúp bạn đi được 80% chặng đường:

Đây cũng là lý do tại sao NotAllowedError hiếm khi nên hiển thị cho người dùng. Nó không phải là thông báo mà người dùng có thể thực hiện.

Việc phân loại theo bối cảnh cũng là lúc tỷ lệ thành công bị chia cắt mạnh nhất. Phân tích tỷ lệ thành công của passkey đo lường tỷ lệ hoàn thành ở Q1 2026 đạt 55-95% cho các luồng xác định thiết bị chưa biết so với 95-99% đối với thiết bị đã biết trả về trên các triển khai B2C quy mô lớn. Nhận dạng nền tảng web iOS trước tiên đạt 85-95% hoàn thành (CDA 0-5%), nền web Android ở 70-85% (CDA 5-10%) và nền web macOS ở 70-85% (CDA 10-15%), trong khi nền web Windows nằm ở mức 45-60% với %CDA ở 55-65% trên Windows 11 và 40-55% trên Windows 10. Đọc khối lượng NotAllowedError mà không chia thiết bị đã biết với chưa biết kết hợp hai cơ chế tỷ lệ thành công hoàn toàn khác nhau.

Một sắc thái quan trọng trong production: một số tác nhân người dùng có thể hiển thị hết thời gian dưới dạng TimeoutError, nhưng nhiều nhóm vẫn thấy tình trạng hết thời gian chờ được thu gọn thành NotAllowedError trong trang tổng quan. Dù bằng cách nào, hãy coi hết thời gian chờ là “nghi thức không hoàn thành” và phân nhóm sử dụng thời gian cùng ngữ cảnh.

Khi bảng điều khiển hệ điều hành bị tắt hoặc hết thời gian chờ, UI của bạn phải ngay lập tức được khôi phục lại và phản ứng mượt mà. Một số quy tắc thực tế:

• khôi phục UI đăng nhập (không hiển thị các spinner đang chạy)
• giữ nguyên trạng thái định danh (không buộc người dùng nhập lại)
• hiển thị một luồng fallback rõ ràng trên cùng một màn hình
• tránh các biểu ngữ mang tính hù dọa đối với các kết quả đã được dự kiến trước

Ngoài những điều cơ bản:

• Xử lý lần hủy đầu tiên như một điều bình thường và cung cấp tùy chọn thử lại với một lời giải thích bình tĩnh. Chỉ sau lần hủy thứ hai, bạn mới nên gợi ý các tùy chọn dự phòng.
• Cho phép xuất hiện tối đa ba lời nhắc tạo thông tin đăng nhập trước thời gian chờ để những người dùng bất ngờ có cơ hội thứ hai.
• Chia lỗi thành hai phần tính đếm số lượng lỗi tạo thông tin đăng nhập và đăng nhập để bạn có thể so sánh hợp lý.
• Phân khúc tỷ lệ lỗi dựa theo Hệ điều hành, trình duyệt và thiết bị để bạn có thể nhận diện xem rào cản thực sự nằm ở đâu.

Nếu tỷ lệ “lượt hủy” thực sự cao, bước tiếp theo là khắc phục nguyên nhân gốc rễ đằng sau: thời gian xuất hiện của lời nhắc, những bất ngờ từ mã QR và mức độ sẵn có thấp.

Hãy bắt đầu với những thay đổi có thể nhanh chóng cải thiện các số liệu:

• Chỉnh sửa thời gian nhắc nhở và kích hoạt người dùng (đặc biệt là trên iOS/Safari).
• Giảm thiểu yếu tố bất ngờ đối với mã QR/kết hợp.
• Cấp quyền cung cấp passkey để các tính năng này chỉ được hiển thị khi khả năng thành công cao.
• Sử dụng các hình thức để tránh hiện lời nhắc nhở khi không có thông tin xác thực cục bộ.
• Xử lý tình trạng mất kết nối mạng: Lỗi mạng trong quá trình xác minh thường được hiển thị như những lỗi chung chung trên máy khách. Triển khai một hàng đợi offline cho các bản ghi từ xa để bạn không bị mất dữ liệu lỗi khi kết nối của người dùng bị ngắt trong quá trình thực hiện phương thức.
• Tạo giới hạn phương thức thông qua API phát hiện để lỗi môi trường không thổi phồng nhóm NotAllowedError của bạn. Hãy bắt đầu với isUVPAA() như rào cản cơ bản nhất, sau đó sử dụng getClientCapabilities() cho những yêu cầu kiểm tra kỹ càng hơn (conditional create, conditional get, vận chuyển lai, trình xác thực nền tảng). Lưu ý rằng các API phát hiện có thể bị gián đoạn cùng với những lần cập nhật hệ điều hành: iOS 26.2 phát hành với một lỗi trên WebKit trong đó isUVPAA() trả về giá trị false đối với tất cả những trình duyệt có nền tảng WKWebView mặc dù passkey hoạt động hoàn toàn bình thường, dẫn tới đột biến đột ngột ở lỗi NotAllowedError đối với 10-25% số lượng người dùng iOS.

Tên lỗi là một mục tiêu luôn di chuyển. Đã có những đề xuất đang được thực hiện để thêm nhiều các lỗi chi tiết hơn liên quan đến WebAuthn (ví dụ, để chia ra “không có thông tin xác nhận” với “người dùng đã hủy”). Tính đến tháng 2 năm 2026, điều này vẫn chưa được áp dụng vào bất kỳ trình duyệt nào, nên tốt nhất là xây dựng hệ thống các nhóm lý do để phân loại nguyên nhân cho riêng mình dựa trên ngữ cảnh và thời gian. Nếu bạn muốn theo dõi hoạt động này, xin hãy xem WebAuthn issue #2062 và bảng giải thích "Mã Lỗi Mới".

Những lỗi khác sẽ xuất hiện ít thường xuyên hơn nhưng vẫn đáng để tìm hiểu khi chúng xuất hiện.

Lỗi AbortError ít khi xuất hiện với số lượng nhiều nếu so với lỗi NotAllowedError, nhưng khi nó xảy ra, lỗi này thường là chẩn đoán mức cao: nghĩa là nghi thức không hoàn thiện bởi vì ứng dụng của bạn không cho yêu cầu được duyệt - điều hướng xảy ra, trạng thái thay đổi hoặc một yêu cầu thứ hai đã được khởi động.

Bạn sẽ gặp những lỗi nào trên giao diện trình duyệt:

Những nguyên nhân thường gặp trong môi trường production bao gồm:

• Cuộc gọi tới WebAuthn được thực hiện đồng thời ở nhiều nơi khác nhau (hai lượt nhắc nhở bị trùng lặp)
• Thay đổi định tuyến/tái kết xuất khi nghi thức đang chạy
• Gọi AbortController.abort() trong lúc chờ thử lại hoặc lúc chờ dọn dẹp hệ thống

Để giải quyết, hãy tập trung vào việc tạo cho những nghi thức một “khu vực kiểm soát”:

• Chỉ cho phép một yêu cầu được hoạt động trong cùng một thời điểm
• Chặn điều hướng trong suốt quá trình nghi thức diễn ra (hoặc hủy bỏ sạch sẽ và hồi phục lại lại UI)
• Coi việc bị gián đoạn là điều khiển luồng mong đợi: hiện lên phím thử lại và luồng fallback

Nếu bạn bắt gặp lỗi AbortError xuất hiện đặc ở những bề mặt được đính kèm hoặc trong những ứng dụng hỗ trợ nhiều tên miền, phần tiếp theo bạn nên kiểm tra chính là SecurityError.

SecurityError là cách trình duyệt thông báo rằng: "bối cảnh này không được phép làm những gì bạn vừa bảo." Về thực tế thì hầu hết tất cả lỗi đều nằm trên cấu hình chứ không phải trên thao tác của người dùng. Trong các đợt phát hành ở production, SecurityError là rất hiếm bởi vì những lỗi trên thường được tìm thấy khi kiểm tra tích hợp. Khi nó hiện lên trên giao diện hoạt động thì có nghĩa là một domain mới, bối cảnh đính kèm hay một nơi điều hướng vừa mới được thêm vào mà thiếu đi các cấu hình WebAuthn hỗ trợ.

Những nguyên do thông dụng bao gồm:

• Không khớp RP ID / nguồn gốc (cho setup gồm nhiều domain)
• Hạn chế đính kèm tên miền chéo (iframe)
• Không đảm bảo được độ an toàn (thiếu HTTPS) hoặc bị chặn phân quyền/chính sách
• .well-known/webauthn hay .well-known/assetlinks.json bị cấu hình sai, bị mất hoặc tạm thời không thể sử dụng. Những lỗi trên hệ thống mạng trong quá trình cần thiết nhất khi mà trình duyệt thu thập thông tin từ những tập tin này sẽ gây ra thất bại. Một góc khuất mà rất nhiều người dùng không để ý: nếu web chính của bạn phải bảo trì, thì những file public này cũng sẽ offline, làm gián đoạn mọi nghi thức liên quan tới WebAuthn của bạn đối với tất cả những bên lệ thuộc vào nó.

Bạn sẽ gặp những lỗi nào trên giao diện trình duyệt:

Trong môi trường production, SecurityError là rất hiếm - hầu hết chúng thường được tìm thấy và loại bỏ trong thời gian kiểm tra. Nếu chúng vẫn xuất hiện, thì lỗi trên chứng chỉ TLS là những lý do duy nhất có khả năng xảy ra nhất.

Vòng lập debug nhanh nhất là:

• Ghi lại các đầu vào origin và RP ID bạn đã dùng
• Tái tạo lại những trong cùng hoàn cảnh như lúc xảy ra lỗi (Top-level vs iframe, Prod Domain vs Staging)
• Nếu bạn đính kèm thông tin để đăng nhập, hãy chắc chắn về chính sách phân quyền đã được cấu hình từ trước (ví dụ như publickey-credentials-create / publickey-credentials-get): MDN Permissions-Policy
• Xác nhận chiến lược đặt tên miền của bạn
• Nếu bạn sử dụng iframe, hãy xác nhận chính sách của hệ thống cho các tiện ích của người dùng

Một khi lỗi SecurityError được giải quyết, những loại lỗi tiếp theo mà bạn cần phải giải quyết kỹ lưỡng là những lỗi thường thể hiện rõ về bug đã được cài đặt: InvalidStateError, ConstraintError và DataError.

Cheatsheet Passkeys. Hướng dẫn thực tế, mẫu triển khai và KPI cho chương trình passkeys.

Nhận cheat sheet

Các lỗi này hiếm khi xảy ra trong một hệ thống passkey hoàn thiện. Khi chúng xuất hiện, chúng thường chỉ ra rằng phần tạo tùy chọn (option generation) bị sai cho một nhóm nhất định hoặc quy trình đang ở sai trạng thái.

Những gì bạn sẽ thấy trong bảng điều khiển trình duyệt:

Ý nghĩa thông thường:

• đăng ký: bạn đã cố tạo một credential đã tồn tại (trùng lặp)
• đăng nhập: ít phổ biến hơn; thường có nghĩa là luồng/trạng thái không nhất quán đối với nền tảng

Xử lý thực tế:

• nếu xảy ra trong đăng ký thủ công, hãy coi nó như “đã được đăng ký” và định tuyến cho phù hợp
• đảm bảo excludeCredentials liệt kê tất cả credential ID hiện có của người dùng để authenticator có thể phát hiện lỗi trùng lặp
• trong lúc conditional create, InvalidStateError là điều được dự kiến và nên được bỏ qua một cách lặng lẽ: điều đó có nghĩa là passkey đã tồn tại trong nhà cung cấp. Điều tương tự áp dụng cho NotAllowedError và AbortError trong quá trình conditional create.

Ý nghĩa thông thường: authenticator không thể đáp ứng các ràng buộc mà bạn yêu cầu.

Nguyên nhân phổ biến:

• thiếu khóa màn hình thiết bị (đặc biệt là Android): nền tảng yêu cầu xác minh sinh trắc học hoặc mã PIN nhưng thiết bị chưa được cấu hình khóa màn hình
• quá khắt khe đối với các giả định về authenticatorAttachment hoặc khóa thường trú
• yêu cầu bắt buộc userVerification trong các nhóm mà chúng không có sẵn

Cách khắc phục: nới lỏng các ràng buộc (khi có thể chấp nhận) hoặc cung cấp một hướng đi thay thế. Đối với thiết bị thiếu khóa màn hình, hãy xem xét phát hiện tình trạng này và hướng dẫn người dùng thay vì thất bại lặng lẽ (Android).

Ý nghĩa thông thường: đầu vào bị biến dạng hoặc không nhất quán.

Nguyên nhân phổ biến:

• sai lầm khi mã hóa (base64 so với base64url)
• id xác thực / định dạng challenge không hợp lệ

Cách khắc phục: xác minh và chuẩn hóa các đầu vào ở ranh giới nơi bạn tạo WebAuthn options. Trong thực tế, DataError gần như vắng bóng trong các hệ thống production trưởng thành - nếu option generation của bạn đã được thử nghiệm, bạn sẽ không thấy điều này trong dashboard.

Nếu các lỗi này đang được kiểm soát, câu hỏi tiếp theo là phạm vi hỗ trợ: người dùng có thất bại vì môi trường không thể thực hiện WebAuthn theo cách bạn mong đợi?

NotSupportedError là một tín hiệu về độ bao phủ, không phải tín hiệu về độ tin cậy. Nó thường có nghĩa là một phân khúc không thể làm những gì bạn yêu cầu (HĐH/trình duyệt quá cũ, thiếu khả năng, tính năng không được kích hoạt).

Những gì bạn sẽ thấy trong bảng điều khiển trình duyệt:

Hai dòng đầu tiên là các DOMException thực sự cho NotSupportedError. Các mục TypeError về mặt kỹ thuật là một loại ngoại lệ khác nhưng đại diện cho cùng một lớp vấn đề: trình duyệt hoặc môi trường không hỗ trợ những gì bạn đã yêu cầu. Lớp chuỗi hóa JSON TypeError phổ biến hơn nhiều trong thực tế so với bản thân DOMException NotSupportedError.

Nguyên nhân phổ biến bao gồm:

• phiên bản trình duyệt/HĐH cũ hơn không hỗ trợ WebAuthn cơ bản
• yêu cầu các tính năng WebAuthn không khả dụng trên nền tảng đó
• thử nghiệm các luồng riêng biệt theo nền tảng trên các thiết bị không được hỗ trợ

Lớp chuỗi hóa JSON là nguồn lớn nhất gây ra lỗi thuộc lớp NotSupportedError trong môi trường production. Về kỹ thuật, chúng hiển thị là TypeError (thiếu phương thức) chứ không phải là DOMException, nhưng đây là nơi bạn sẽ gặp chúng. Hai nguyên nhân gốc rễ khác biệt:

1. Trình duyệt không hỗ trợ các phương thức chuỗi hóa JSON của WebAuthn. Trình duyệt có navigator.credentials nhưng không có PublicKeyCredential.parseCreationOptionsFromJSON / parseRequestOptionsFromJSON. Điều này chiếm khoảng 90% gia đình lỗi này, tập trung ở các phiên bản Safari và Chrome cũ hơn. Nếu thư viện client của bạn phụ thuộc vào các phương thức này mà không có dự phòng, thì điều này sẽ tạo ra lượng lỗi đáng kể.
2. Các tiện ích mở rộng trình quản lý mật khẩu phá vỡ .toJSON(). Các tiện ích mở rộng như Bitwarden, LastPass, hoặc 1Password có thể chặn buổi lễ và trả về một đối tượng trông giống như thông tin xác thực nhưng không phải là phiên bản thực sự của PublicKeyCredential. Việc gọi .toJSON() trên đó có thể ném ra lỗi, trả về undefined, hoặc đối tượng hoàn toàn là null. Điều này chiếm khoảng 10% nhưng đặc biệt gây bối rối để gỡ lỗi vì các thông báo lỗi khác nhau tùy theo trình duyệt.

Xử lý nên dứt khoát và nhanh chóng:

• quay về dự phòng mật khẩu/OTP ngay lập tức
• ghi lại phân khúc để bạn có thể định lượng khoảng trống bao phủ
• tránh hiển thị CTA của passkey trên các phân khúc sẽ liên tục gặp lỗi

Nếu phạm vi hỗ trợ có vẻ ổn định nhưng vẫn gặp lỗi ở các nhóm thiết bị cụ thể, bạn có thể đang xử lý các sự cố ở tầng nền tảng được hiển thị thông qua UnknownError.

UnknownError là một khái niệm tổng hợp để chỉ các lỗi về trình xác thực/hệ điều hành không phù hợp để xếp vào các loại lỗi khác. Thường đây chỉ là vấn đề tạm thời nhưng nó cũng có thể tăng vọt sau khi cập nhật hệ điều hành.

Những lỗi bạn sẽ thấy trên bảng điều khiển trình duyệt:

Cách xử lý trong thực tế:

• thiết kế UX hỗ trợ thử lại thân thiện với người dùng (không đổ lỗi cho người dùng)
• thu thập phiên bản hệ điều hành/bản dựng cũng như ngữ cảnh về trình quản lý thông tin xác thực nếu có thể
• theo dõi hiện tượng gia tăng đột biến lỗi ở một phân khúc sau khi cập nhật hệ điều hành

Một nguồn lỗi nhỏ không phù hợp với loại DOMException: các tiện ích mở rộng về trình quản lý mật khẩu của trình duyệt (như Bitwarden, LastPass, 1Password, và những ứng dụng khác) có thể chặn cuộc gọi API WebAuthn và đưa ra các phản hồi phi tiêu chuẩn. Dù không nhiều nhưng đây là những lỗi cần theo dõi vì chúng ảnh hưởng nhất quán đến các phân khúc người dùng cụ thể và những triệu chứng đi kèm thì rất khó hiểu: phương pháp không có trong đối tượng xác thực được trả về, loại lỗi bất ngờ, hoặc các phản hồi bất thường không phù hợp với thông tin lỗi WebAuthn đã cung cấp. Chúng thường sẽ hiển thị dưới dạng UnknownError hoặc dạng ngoại lệ chưa phân loại. Nếu bạn thấy tỉ lệ gặp lỗi tăng cao ở các trình duyệt cụ thể mà không có lý giải cho cấp độ hệ điều hành, hãy kiểm tra xem có sự can thiệp của tiện ích mở rộng nào không.

Từ nãy đến giờ chúng ta đã nhắc qua tất cả các tên lỗi trên trình duyệt web. Nhưng nếu bạn sử dụng các ứng dụng native thì bức tranh tổng thể về lỗi sẽ khác biệt - và có phần tốt hơn nhiều.

Tất cả những thông tin bên trên là dành cho các trình duyệt web. Ứng dụng native - iOS với khung cấu trúc ASAuthorization, Android với Credential Manager - đều chia sẻ các nhóm lỗi cơ bản chung nhưng khác biệt ở các điểm quan trọng sau:

1. "Không có credentials" là một tín hiệu khác biệt. Trên web, các trình duyệt sẽ gộp hai trường hợp "không có credential khả dụng" và "người dùng hủy" vào chung một loại lỗi NotAllowedError vì các lý do liên quan đến bảo mật quyền riêng tư. Trên nền tảng native, việc dùng lệnh preferImmediatelyAvailableCredentials trên iOS (ASAuthorizationController) hoặc setPreferImmediatelyAvailableCredentials(true) trên Android (GetCredentialRequest) sẽ báo cho hệ điều hành chỉ hiện các loại credential đã có sẵn trong thiết bị và báo lỗi ngay nếu không tìm thấy. Từ đó ta sẽ thu được một lệnh "không có credentials" rõ ràng mà trên nền tảng web không thể làm được.

2. Trạng thái về nhà cung cấp credential được hiển thị. Nền tảng native trong một số điều kiện có thể thông báo cho bạn khi không có nhà cung cấp credential nào (Google Password Manager, iCloud Keychain, 1Password, v.v.) được cài đặt, được định cấu hình, hoặc được cài mặc định và phản hồi lại. Trên web, loại thông tin này bị ẩn sau các thông báo lỗi NotAllowedError khó hiểu.

3. Thông báo lỗi mang tính chi tiết hơn. Khi người dùng đã tải app về, hệ điều hành sẽ hiển thị chi tiết các lỗi chẩn đoán sâu hơn. Các lý do liên quan đến bảo mật quyền riêng tư làm cho trình duyệt web mù mờ sẽ không áp dụng ở đây khi mà ứng dụng đã được tải về. iOS sẽ hiển thị thông báo với ngôn ngữ được thiết bị sử dụng. Android hiển thị các loại lỗi có cấu trúc cùng với chuỗi phân tích. Từ đó giúp cho việc sửa lỗi dễ hơn nhưng đồng nghĩa với việc bạn phải biết nguyên do xảy ra lỗi với dạng lỗi của hệ điều hành hiện tại.

iOS xuất lỗi passkey bằng khung cấu trúc ASAuthorization. Tất cả lỗi sẽ chuyển về authorizationController(controller:didCompleteWithError:) dưới dạng đối tượng NSError.

Phân nhóm dựa vào domain và code, không phải vào tin nhắn. Main error domain là com.apple.AuthenticationServices.AuthorizationError (ASAuthorizationError.errorDomain). Cast lỗi với let nsError = error as NSError và gán với .domain và .code. Đừng bao giờ chọn .localizedDescription trong lúc đang phát hành bản production - tin nhắn của Apple được dịch qua hơn 30 ngôn ngữ và có thể thay đổi trên các phiên bản hệ điều hành. Các dòng tin nhắn phía dưới rất hữu dụng trong việc nhận biết các lỗi trong bản báo cáo nhưng lại không phải là tiêu chí để ta phân loại lỗi.

Mã lỗi Public ASAuthorizationError:

Sự khác biệt quan trọng nhất cho môi trường production: từ iOS 18, credential trùng lặp sẽ trả lại mã code riêng 1006 (MatchedExcludedCredential). Ở iOS 17 trở xuống, credential trùng lặp được giấu trong dòng code 1004 (Failed). Ở iOS 18+, sự khác biệt nằm ở cấu trúc (mã code khác nhau), chứ không phải là ở văn bản.

Các lỗi runtime phổ biến (tham khảo cấp độ nhật ký):

Những tin nhắn này xuất hiện trong phần localizedDescription hoặc trong userInfo cho từng trường hợp lỗi cụ thể. Hãy dùng chúng để tìm kiếm nhật ký và sửa lỗi, đừng dùng chúng để phân loại theo lập trình.

Thông điệp nội địa hóa "không có thông tin xác thực" (code 1005):

Khi sử dụng preferImmediatelyAvailableCredentials và không có passkey nào, iOS sẽ trả về mã lỗi 1005 (NotInteractive) đi kèm với ngôn ngữ địa phương mà thiết bị sử dụng. Điều này là đặc quyền ở các ứng dụng native - các web browser không có loại tín hiệu này. Loại thông báo này luôn bắt đầu với phần The operation couldn't be completed. theo sau đó là thứ ngôn ngữ được thiết bị sử dụng:

Các thiết bị ở chế độ ngôn ngữ tiếng Anh thường sẽ giải quyết lệnh "không có thông tin xác nhận" này tại cấp độ API trước khi cấu trúc ASAuthorization gửi lại một mã lỗi dạng địa phương hóa, đó là lý do mà không có phiên bản nào của tiếng Anh xuất hiện ở phần trên. Về mặc lập trình, mã lỗi code 1005 thay vì phân tích các đoạn chữ đó.

Android hiển thị các lỗi liên quan đến passkey qua ứng dụng lập trình giao diện Credential Manager (androidx.credentials). Thông báo của nó bao gồm một thông báo chính cùng với nguyên do được giải thích vô cùng tỉ mỉ. Nếu so với iOS, Android lại cung cấp nhiều loại lỗi với cấu trúc hoàn chỉnh hơn và lý do cũng vô cùng dễ hiểu so với phần lý do của ứng dụng kia.

Người dùng từ chối thao tác & phân loại chứng chỉ:

Lỗi về cấu hình và bảo mật:

Nền tảng hệ điều hành và lỗi của ứng dụng bên xác thực:

Biểu đồ sau đây sẽ cho thấy cách tất cả các tầng được thảo luận ở trên - Hạ tầng (Infrastructure), Môi trường (Environment), Loại hoạt động (Operation type), Phân loại (Classification) và Phát hiện (Detection) - kết nối từ đầu đến cuối như thế nào. Đây là mô hình tinh thần bạn nên ghi nhớ khi thiết kế hệ thống theo dõi lỗi của mình.

flowchart TD
    %% Global Styles
    classDef expected fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
    classDef unexpected fill:#ffebee,stroke:#c62828,stroke-width:2px;
    classDef network fill:#fff3e0,stroke:#ef6c00,stroke-dasharray: 5 5;
    classDef env fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px;
    classDef action fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    %% --- LEFT SIDE: NETWORK & SERVER ---
    subgraph Infrastructure ["Hạ tầng (Máy chủ/Mạng)"]
        direction TB
        ServerErr["Lỗi Máy chủ<br/>500 / Lỗi Logic"]:::network
        NetErr["Lỗi Mạng<br/>Quá thời gian / 400 Bad Request"]:::network

        ServerErr & NetErr -->|Hiển thị dưới dạng| ClientManifest["Lỗi Chung chung trên Máy khách"]
    end

    %% --- CENTER: THE ENVIRONMENT STACK (From Sketch) ---
    subgraph Environment ["Môi trường (Phía Máy khách)"]
        direction TB

        %% Layer 1: Platform Type
        subgraph Type ["Tầng 1: Nền tảng"]
            Web["Web / Trình duyệt"]
            Native["Native / Ứng dụng"]
        end

        %% Layer 2: OS Context
        subgraph OS_Layer ["Tầng 2: Hệ điều hành & Phiên bản"]
            OS_Web["HĐH: Windows, macOS, Linux"]
            OS_Nat["HĐH: iOS, Android"]
            OS_Ver["Phiên bản HĐH / Cài đặt<br/>(Khóa màn hình, Sinh trắc học)"]

            Web --> OS_Web
            Native --> OS_Nat
            OS_Web & OS_Nat --> OS_Ver
        end

        %% Layer 3: Client Software
        subgraph Client_Layer ["Tầng 3: Phần mềm Máy khách"]
            Browser["Trình duyệt: Chrome, Safari, Edge<br/>+ Phiên bản"]
            App["Ứng dụng Native / WebView<br/>+ Phiên bản Ứng dụng"]

            OS_Ver --> Browser
            OS_Ver --> App
        end

        %% Layer 4: WebAuthn Operation
        subgraph Op_Layer ["Tầng 4: Hoạt động WebAuthn"]
            OpType{"Loại Hoạt động"}

            Login["Đăng nhập<br/>(navigator.credentials.get)"]
            Reg["Đăng ký<br/>(navigator.credentials.create)"]

            Browser & App --> OpType
            OpType --> Login
            OpType --> Reg
        end

        %% Layer 5: Sub-types & Complexity
        subgraph Modality ["Tầng 5: Hình thức & Độ phức tạp"]
            Sub_CUI["CUI / Conditional UI"]
            Sub_Auto["Hoạt động Tự động"]
            Sub_CDA["CDA / Xác thực Đa thiết bị"]

            Login & Reg --> Sub_CUI
            Login & Reg --> Sub_Auto
            Login & Reg --> Sub_CDA
        end
    end

    %% --- BOTTOM: CLASSIFICATION & ACTION (The "What here?" section) ---
    subgraph Analysis ["Phân tích Lỗi & Runtime"]
        direction TB

        %% Classification
        Classification{"Phân loại"}

        Exp["Lỗi Dự kiến<br/>(Người dùng Hủy)"]:::expected
        Unexp["Lỗi Không Dự kiến<br/>(Hệ thống/Sự cố/Không xác định)"]:::unexpected

        ClientManifest --> Classification
        Sub_CUI & Sub_Auto & Sub_CDA --> Classification

        Classification --> Exp
        Classification --> Unexp

        %% Detection Logic
        subgraph Detection ["Mục tiêu Phát hiện"]
            P1["P1: Vấn đề Đăng nhập"]
            P2["P2: Vấn đề Tạo"]
            Baseline["Phát hiện Lệch Chuẩn<br/>(Tăng Lỗi Dự kiến)"]
            NewErr["Phát hiện Dấu hiệu Bất thường<br/>(Tăng Lỗi Không Dự kiến)"]
        end

        Exp --> Baseline
        Unexp --> NewErr
        Exp & Unexp --> P1 & P2

        %% Actionable Outcomes
        subgraph Action ["Hành động Khắc phục"]
            Fix["Triển khai Hotfix / Phiên bản Mới"]:::action
            Fallback["Kích hoạt Dự phòng Tự động<br/>(Vô hiệu hóa Passkey)"]:::action
        end

        P1 & P2 & NewErr --> Fix
        P1 & P2 & NewErr --> Fallback
    end

    %% Connectors
    Infrastructure -.-> Environment

Hiểu biết quan trọng nhất là: một tham số dạng error.name thô chỉ có thể hiểu được khi bạn xác định tầng lớp nào trong Environment tạo ra lỗi, Operation (Loại hoạt động) nào đang diễn ra và liệu lỗi là do được dự kiến hay không. Dưới đây là những cách để có thể lưu trữ lịch sử báo cáo lỗi.

Phần lớn các phân loại lỗi trong bài viết này có thể được thực hiện chỉ với tín hiệu ở phía máy khách. Một SDK quan sát front-end sẽ thu thập đủ bối cảnh cần thiết cho việc phân nhóm hầu hết các loại lỗi về chứng chỉ WebAuthn. Đây cũng là cách SDK quan sát của Corbado được thiết kế: tầng phía máy khách xử lý việc quy chụp lỗi, thời gian, ngữ cảnh hoạt động và phát hiện nền tảng. Nhật ký phía máy chủ bổ sung thêm lớp thứ hai cho các lỗi mà chỉ backend mới có thể thấy.

Yêu cầu chính: mỗi lần thử cần được kết nối từ đầu đến cuối một cách trơn tru. Một ID tương quan dùng chung (ví dụ: auth_flow_id) sẽ kết nối thông tin phía khách hàng cùng với kết quả kiểm tra phía server.

Sự cố kiểm tra server là một phần sau khi trình duyệt trả lại kết quả chứng chỉ và challenge đã được đăng kí. Đây nên là loại mã lỗi định dạng chi tiết cấu trúc thay vì lưu tại cùng một nơi với các loại tên ngoại lệ DOMException. Đọc phần: WebAuthn Server Implementation.

Nếu bạn cần tham khảo cho phễu thông tin (rút gọn hoặc loại bỏ các nhóm khách/đối tượng đã truy cập phễu thông qua các thao tác ở từng bước nhỏ): hãy vào trang passkey telemetry to understand drop-offs.

Đăng ký Passkeys Substack để nhận tin mới nhất.

Đăng ký

Với dữ liệu này, kết luận trở nên đơn giản: hầu hết các "lỗi" đều có thể được xử lý bằng các bản sửa lỗi UX, bản sửa lỗi phạm vi hỗ trợ hoặc bản sửa lỗi cấu hình. Tuy nhiên, việc xây dựng và duy trì sự phân loại này cho riêng bạn đòi hỏi nhiều công sức liên tục.

Danh sách cần ghi log ở trên ghi lại các tín hiệu thô. Trong môi trường production ở quy mô lớn, chỉ riêng error.name là không đủ. Việc tự xây dựng hệ thống phân loại này đòi hỏi nỗ lực liên tục: các thông báo lỗi thay đổi theo từng bản phát hành trình duyệt và HĐH, các nhà cung cấp ứng dụng quản lý mật khẩu đưa ra các bản cập nhật làm thay đổi hành vi của buổi lễ và các dấu hiệu lỗi mới xuất hiện với mỗi đợt ra mắt tính năng.

Cùng một NotAllowedError có thể mang 6 ý nghĩa khác nhau dựa trên ba tiêu chí mà trình duyệt không tách biệt cho bạn:

Đây là vấn đề mà SDK observability của Corbado được xây dựng để giải quyết. Nó là một tích hợp frontend gọn nhẹ, nằm trên hệ thống triển khai passkey hiện có của bạn, hoạt động với bất kỳ máy chủ WebAuthn nào và bất kỳ IDP nào, và tự động phân loại từng lỗi WebAuthn dựa trên cả ba tiêu chí:

Đây là tầng Quan sát (Observe): khả năng hiển thị chi tiết về những gì đang xảy ra mà không cần thay đổi quá trình triển khai của bạn.

Bảng điều khiển quản lý của Corbado hỗ trợ hai đường hướng điều tra:

Top-down (Từ dashboard đến nguyên nhân gốc rễ):

1. Giám sát hai loại hiện tượng bất thường riêng biệt:
   • Lỗi Dự kiến tăng (Lệch chuẩn): Liệu một môi trường cụ thể (ví dụ: iOS 18.2 trên iPhone 15) có nhận thấy sự gia tăng đều đặn về số "người dùng hủy"? Điều này thường báo hiệu sự vướng mắc trong UX do bản cập nhật HĐH gây ra.
   • Lỗi Không dự kiến tăng (Đột biến): Một lỗi hoàn toàn mới hoặc lỗi tăng vọt đột ngột. Điều này thường báo hiệu về một sự thay đổi gây ra sự cố (cập nhật nội bộ trên stack IDP) hoặc sự thụt lùi ở một phiên bản trình duyệt mới.
2. Ưu tiên theo tác động:
   • P1: Các vấn đề về Đăng nhập. Nếu tỷ lệ đăng nhập thành công giảm, cảnh báo ngay lập tức.
   • P2: Các vấn đề về Tạo. Theo dõi xu hướng, nhưng tránh đánh thức kỹ sư vào ban đêm vì sự tăng vọt "người dùng hủy" trong luồng tạo passkey.
3. Phân tích sâu vào Môi trường: Dùng các tiêu chí chi tiết (Phần cứng, Cài đặt Auth) để cô lập xem sự cố này mang tính toàn cầu hay chỉ xảy ra cụ thể đối với các "thiết bị Samsung cài Android 14".
4. Khắc phục: Nếu phát hiện một sự gia tăng đột biến nghiêm trọng, hãy chuẩn bị sẵn sàng một Công tắc ngắt (Kill Switch). Tự động hoặc thủ công vô hiệu hóa passkey cho môi trường đó và quay về dùng OTPs/Passwords để bảo vệ tỷ lệ đăng nhập trong khi bạn điều tra.

Bottom-up (Từ các loại lỗi đến hậu quả):

1. Bắt đầu từ chế độ hiển thị phân loại lỗi. Xét duyệt lại các loại lỗi đã phân loại và quy mô khối lượng lỗi.
2. Sàng lọc thông tin để lập ra danh sách bản đồ tổng quan các lỗi vừa xuất hiện (như là thông tin về một lỗi mới từ bản update vừa rồi).
3. Các lỗi có tác động chéo đến thay đổi KPI và được xuất hiện dưới dạng thông báo trên dashboard của người dùng, nên tỷ lệ gặp loại lỗi cụ thể đột nhiên tăng đột biến sẽ được tự động liên kết với số liệu mà nó gây ảnh hưởng.

Tất cả các con đường đều dẫn tới: "top-down" báo cho bạn một thông tin xấu, trong khi "bottom-up" sẽ cho bạn biết về lý do đó. Hệ thống Phân tích Báo cáo từ AI hỗ trợ liên kết hai chiều với việc trả lời những câu hỏi từ các văn bản tự nhiên qua dữ liệu liên quan đến lỗi và việc cải thiện các số liệu đo lường.

Các nhóm muốn khắc phục hoặc tận dụng lại các thông tin này có thể thông qua Adopt - phần mềm cung cấp những chứng chỉ tình báo (passkey intelligence) giúp khởi tạo giao diện điều hướng tự động trên web, tối ưu hóa quá trình đăng ký chứng chỉ và sửa chữa thông tin lỗi trên passkey. Đối với những môi trường được quy định nghiêm ngặt hay có thông tin dữ liệu cực lớn, bản Enterprise có thể cấp quyền single-tenant hosting, cùng với SIEM integration và hệ thống tương thích cho PSD2.

Nhận whitepaper passkey miễn phí cho doanh nghiệp.

Nhận miễn phí

Các loại lỗi WebAuthn không phải là định kiến cuối cùng. Chúng chỉ là các gợi ý - và chúng sẽ chỉ trở nên quan trọng khi bạn có khả năng kết nối và tìm ra các loại dữ liệu hoạt động đang có trên trình duyệt, thời gian và quá trình xử lý của nền tảng mà bạn dùng.

• Các tên lỗi WebAuthn phổ biến nhất trong môi trường production thường mang ý nghĩa gì? Phần lớn chúng sẽ được chia thành một vài nhóm nhỏ có liên quan đến: phân quyền quản lý quy trình sử dụng cho người dùng (NotAllowedError), dữ liệu ứng dụng (AbortError), ngữ cảnh/cấu hình bảo mật (SecurityError), hay trạng thái phân quyền (InvalidStateError, ConstraintError, DataError). Phần lớn quy mô trong môi trường sẽ nằm ở NotAllowedError, phần nhiều cũng chính là loại thông tin dễ dự kiến nhất (người dùng từ chối thao tác).
• Làm cách nào để bạn phân biệt NotAllowedError? Dùng thời gian (bị từ chối ngay lập tức so với người dùng hủy bỏ và hết thời gian chờ), bộ quy chuẩn QR/công cụ hybrid (thông tin không khớp/khả dụng), dữ liệu thông tin về phân quyền kích hoạt (đặc biệt là iOS/Safari) và cách chúng vận hành (thông qua Conditional UI với hình thức modal log trên passkey hay là từ Conditional create). Đừng coi tất cả NotAllowedError là một loại lỗi hoạt động chung biệt.
• Tại sao việc phân loại này lại quan trọng? Cùng một lỗi error.name nhưng khi ở trình thông báo của conditional UI lại là các mã code hoàn toàn khác biệt so với khi ở trình điều hướng cho conditional create, hoặc là phần thiết lập passkey truyền thống. Xác minh một log thuộc về loại nào cùng chung với loại lỗi đó là chìa khóa duy nhất chuyển NotAllowedError thành một loại lỗi có thể quản lý được.
• Dữ kiện nào là loại quan trọng nhất để giúp cho việc debug trở nên dễ dàng hơn? Bao gồm error.name, loại hoạt động, thời lượng, loại hình đang sử dụng, và liệu có phải là hình thức ứng dụng/thiết lập lai nào đã được mở lên không, Hệ điều hành (hay trình duyệt, ứng dụng), cùng với thông tin kết nối (auth_flow_id) và các đoạn mã lỗi server rõ ràng.

Hai nguyên tắc vàng được áp dụng trên tất cả mọi loại lỗi: đừng bao giờ để người dùng nhìn thấy các lỗi thô của trình duyệt - luôn tạo cho họ một cách để dự phòng một cách rõ ràng nhất - và nên chia các cách quản lý cục bộ của nội bộ riêng và không được dính líu gì với hệ thống ngoại bộ khi có vấn đề. Các thiết lập và những phương pháp trên đôi khi phải tùy chỉnh cho phù hợp dựa theo phần cứng để tránh phát sinh ra nhiều hơn vì chúng sẽ gây rối hoặc bị can thiệp bởi mã bảo vệ của máy/ứng dụng bảo vệ của bên thứ 3 nên không có công thức cho mọi trường hợp. Ở những hệ thống quy mô lớn, liên kết các loại máy, những bản cập nhật của từng loại sẽ giúp cho việc phát hiện ra lỗi trở nên thường xuyên hơn. Nếu có thể, hãy dùng observability SDK được kết hợp từ nhiều thông số khác nhau thay vì làm mới từ ban đầu.

Về Corbado

Corbado là Authentication 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 →

Trên web, các trình duyệt gộp cả hai trường hợp vào NotAllowedError vì lý do bảo mật quyền riêng tư, do đó bạn không thể phân biệt chúng trực tiếp. Hãy sử dụng thời gian làm yếu tố thay thế: lỗi xảy ra dưới 1 giây thường có nghĩa là do môi trường từ chối hoặc thiếu khả năng, trong khi lỗi từ 1-15 giây ám chỉ người dùng đã thấy và đóng hộp thoại. Trên các ứng dụng iOS và Android native, việc thiết lập preferImmediatelyAvailableCredentials trước khi gửi yêu cầu cung cấp cho bạn một tín hiệu "không có credentials" rõ ràng (mã 1005 trên iOS, GetCredentialRequest trên Android) trước khi giao diện người dùng hiển thị.

Trong các đợt triển khai passkey quy mô lớn được tối ưu hóa, trên 95% số lỗi WebAuthn được ghi lại đều là các trường hợp người dùng hủy theo dự kiến chứ không phải lỗi hệ thống. Việc theo dõi lượng error.name thô mà không tách biệt "người dùng đã đóng lời nhắc" khỏi các lỗi hỏng hóc thật sự sẽ thổi phồng các chỉ số đo lường lỗi và che đậy những sự cố đang ẩn chứa sau lượng NotAllowedError. Hãy phân chia số lượng dựa theo loại hoạt động, coi việc người dùng hủy giống như cách ta xử lý các tình huống đối với SecurityError, ConstraintError và DataError.

Mã 1005 trên iOS (NotInteractive) có nghĩa là không có passkey nào khả dụng trên thiết bị khi preferImmediatelyAvailableCredentials được đặt trên ASAuthorizationController, và không có giao diện người dùng nào được hiển thị cho người dùng. Đây là tín hiệu sạch "không có passkey tồn tại trên thiết bị này" mà các trình duyệt web không thể cung cấp do những hạn chế về quyền riêng tư. Luôn phân loại dựa trên mã số này, thay vì dựa trên localizedDescription, bởi vì thông báo của Apple được bản địa hóa sang hơn 30 ngôn ngữ và có thể thay đổi theo từng phiên bản hệ điều hành.

Trong quá trình conditional create, NotAllowedError, AbortError và InvalidStateError đều là các kết quả nằm trong dự kiến và nên được bỏ qua một cách lặng lẽ thay vì hiển thị lên như một lỗi. NotAllowedError biểu thị khả năng tự động điền không có sẵn hoặc trang đã mất tiêu điểm, trong khi InvalidStateError có nghĩa là passkey đã tồn tại trong nhà cung cấp. Trước khi thử gọi, hãy sử dụng getClientCapabilities() để xác nhận hỗ trợ của conditionalCreate và kiểm tra trạng thái hiển thị của tài liệu nhằm tránh làm tăng số lượng lỗi của bạn.

Hãy ghi nhận loại hoạt động (conditional UI, đăng nhập modal, tạo thủ công, conditional create hoặc nối thêm tự động), thời gian từ khi bắt đầu hoạt động đến khi xảy ra lỗi, phiên bản hệ điều hành, phiên bản trình duyệt, mẫu phần cứng, xem giao diện mã QR/hybrid có xuất hiện hay không và một ID tương quan để liên kết với nhật ký phía máy chủ. Các sự cố từ chối xác minh của máy chủ như không khớp challenge, chữ ký không hợp lệ và không tìm thấy credential nên được lưu lại dưới dạng các mã có cấu trúc rõ ràng, không được trộn lẫn với các tên DOMException ở phía máy khách. Nhờ kết hợp những tín hiệu này, bạn có thể phân loại phần lớn các lỗi vào các nhóm hành động rõ ràng mà không cần phải đoán mò.