WebAuthn Transports: Giải Thích Về Phương Thức Internal và Hybrid

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Lưu ý: Theo đặc tả WebAuthn, mảng transports rỗng có nghĩa là tất cả các phương thức đều được hỗ trợ.

Khi triển khai passkey trên các nền tảng khác nhau, các nhà phát triển phải đối mặt với một quyết định quan trọng:

• Chúng ta nên xử lý WebAuthn transports, đặc biệt là các phương thức internal và hybrid, như thế nào để đảm bảo trải nghiệm xác thực tối ưu trên nhiều thiết bị?

Câu trả lời nằm ở việc hiểu rõ WebAuthn transports—một chi tiết kỹ thuật quyết định cách các trình xác thực giao tiếp với các bên tin cậy (relying party). Mặc dù về lý thuyết, các phương thức này có vẻ đơn giản, nhưng việc triển khai chúng lại khác nhau đáng kể trên các trình duyệt web, ứng dụng iOS native và Android native, đặc biệt là trong việc xử lý các phương thức internal và hybrid.

Bài viết này xem xét cách WebAuthn transports hoạt động trên các nền tảng khác nhau và trình bày hai cách tiếp cận riêng biệt để xử lý các phương thức internal và hybrid—mỗi cách đều có những ưu và nhược điểm riêng.

Bài viết này bao gồm:

1. WebAuthn transports: internal, hybrid và các trình xác thực nền tảng trên web, iOS và Android
2. Hai cách tiếp cận: tuân thủ đặc tả so với xử lý tối ưu hóa các phương thức internal và hybrid
3. Các thực hành tốt nhất và khuyến nghị khi triển khai xác thực đa thiết bị

WebAuthn transports định nghĩa các phương thức giao tiếp giữa trình xác thực và thiết bị của người dùng. Đặc tả WebAuthn Level 3 định nghĩa sáu loại phương thức:

usb: Được sử dụng bởi các khóa bảo mật phần cứng kết nối qua cổng USB, chẳng hạn như YubiKeys hoặc các token bảo mật FIDO2 khác.

nfc: Cho phép giao tiếp với trình xác thực thông qua Near Field Communication (Giao tiếp tầm gần), cho phép người dùng chạm khóa bảo mật hoặc các thiết bị hỗ trợ NFC.

ble: Hỗ trợ xác thực qua Bluetooth Low Energy, cho phép giao tiếp không dây với các trình xác thực bên ngoài.

smart-card: Được sử dụng cho các đầu đọc thẻ thông minh, cho phép xác thực qua thẻ thông minh.

hybrid: Cho phép xác thực trên nhiều thiết bị, thường là khi người dùng quét mã QR để xác thực chéo các thiết bị—chẳng hạn như dùng điện thoại để xác thực trên trình duyệt máy tính, hoặc ngược lại. Phương thức này có thể kích hoạt lời nhắc mã QR trên cả máy tính và thiết bị di động, điều này không phải lúc nào cũng mong muốn tùy thuộc vào ngữ cảnh. Lưu ý: hybrid đã được thêm vào trong WebAuthn Level 3.

internal: Trình xác thực được nhúng ngay bên trong thiết bị—như iCloud Keychain (xác minh qua Face ID hoặc Touch ID) trên iPhone, Windows Hello trên PC, hoặc Google Password Manager trên các thiết bị Android. Đây là các trình xác thực nền tảng (platform authenticators).

Khi một passkey được tạo, trình xác thực sẽ báo hiệu các phương thức mà nó hỗ trợ. Thông tin này được gửi đến bên tin cậy (backend của bạn), nơi sẽ lưu trữ nó cùng với thông tin xác thực (credential). Trong quá trình xác thực, bên tin cậy gửi lại các phương thức này cho client trong danh sách allowCredentials, giúp trình duyệt hoặc nền tảng quyết định phương thức xác thực nào sẽ đề xuất cho người dùng.

Việc xử lý transport khác nhau đáng kể giữa các nền tảng, tạo ra những thách thức về tương thích mà các nhà phát triển phải đối mặt.

Các trình duyệt nhận thông tin transport từ các trình xác thực và tuân thủ nó trong các luồng xác thực. Khi bạn tạo một passkey trong Chrome, Safari hoặc Edge, trình quản lý thông tin xác thực của trình duyệt sẽ cung cấp dữ liệu transport khác nhau tùy thuộc vào trình xác thực cơ bản:

Trình xác thực nền tảng: Windows Hello chỉ cung cấp ["internal"], phản ánh bản chất gắn liền với thiết bị của nó. Tuy nhiên, khi Chrome sử dụng Google Password Manager làm trình xác thực, nó cung cấp ["internal", "hybrid"] vì Google Password Manager hỗ trợ xác thực đa thiết bị thông qua điện thoại Android.

Khóa bảo mật phần cứng: Cung cấp các phương thức cụ thể như ["usb", "nfc"] dựa trên khả năng thực tế của chúng.

Trình quản lý thông tin xác thực đồng bộ qua đám mây: iCloud Keychain trong Safari và Google Password Manager trong Chrome thường cung cấp ["internal", "hybrid"] để hỗ trợ cả luồng xác thực cục bộ và đa thiết bị.

Thông tin này được truyền tải một cách đáng tin cậy trong môi trường web, mặc dù các phương thức cụ thể phụ thuộc vào trình xác thực nào mà trình duyệt chọn để lưu trữ thông tin xác thực.

Tài liệu tham khảo: W3C WebAuthn Specification

Credential Manager API của Android hoạt động tương tự như các trình duyệt web. Khi tạo passkey trong các ứng dụng Android native, Credential Manager cung cấp thông tin transport phản ánh hành vi trên web—các trình xác thực nền tảng báo cáo khả năng của chúng một cách chính xác, và hệ thống xử lý dữ liệu transport một cách nhất quán. Các nhà phát triển Android có thể tin tưởng vào thông tin này mà không cần xử lý đặc biệt.

Tài liệu tham khảo: Android Credential Manager

iOS lại có một tình huống phức tạp hơn. AuthenticationServices framework của Apple xử lý các phương thức transport khác nhau tùy thuộc vào loại trình xác thực:

Trình xác thực nền tảng (iCloud Keychain, xác minh qua Face ID hoặc Touch ID): Thường trả về mảng transport rỗng trong quá trình tạo passkey. Điều này không có nghĩa là passkey không có khả năng transport—mà chỉ đơn giản là iOS không báo cáo chúng một cách tường minh. Theo tiêu chuẩn WebAuthn, việc bỏ qua transports có nghĩa là bất kỳ phương thức nào cũng được chấp nhận, vì vậy xác thực hybrid vẫn sẽ hoạt động.

Khóa bảo mật: Cung cấp thông tin transport (ví dụ: ["usb"], ["nfc"]) khi được sử dụng với các thiết bị iOS, theo mô hình dự kiến.

Tài liệu tham khảo: Apple AuthenticationServices

Các nhà phát triển đứng trước một lựa chọn: tuân thủ nghiêm ngặt đặc tả, hoặc tối ưu hóa các phương thức internal và hybrid để cải thiện trải nghiệm người dùng. Mỗi cách tiếp cận đều có những ưu và nhược điểm.

Cách tiếp cận này tuân thủ đặc tả WebAuthn: sử dụng các phương thức transports chính xác như được cung cấp bởi trình xác thực trong quá trình đăng ký thông tin xác thực, và gửi lại chúng không thay đổi trong quá trình xác thực.

Triển khai: Khi một passkey được tạo, hãy lưu trữ mảng transports từ phản hồi của trình xác thực. Trong quá trình xác thực, bao gồm chính xác các phương thức này trong danh sách allowCredentials:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Ưu điểm:

• Tuân thủ đặc tả: Tuân thủ chính xác các tiêu chuẩn WebAuthn, đảm bảo tương thích với các bản cập nhật nền tảng trong tương lai
• Độ tin cậy của khóa bảo mật: Hoạt động hoàn hảo với các khóa bảo mật phần cứng (YubiKeys, v.v.) luôn cung cấp thông tin transport chính xác
• Ngăn chặn các tùy chọn không hợp lệ: Tránh đề xuất các phương thức xác thực thực sự không được hỗ trợ—ví dụ, sẽ không kích hoạt mã QR cho các thông tin xác thực của Windows Hello

Nhược điểm:

• Hành vi mảng rỗng của iOS: Các trình xác thực nền tảng trên iOS trả về mảng transports rỗng, theo đặc tả có nghĩa là "bất kỳ phương thức nào"—điều này có thể hiển thị tất cả các tùy chọn xác thực bao gồm cả khóa bảo mật
• Có thể hiển thị các tùy chọn không mong muốn: Có thể hiển thị các tùy chọn khóa bảo mật (USB, NFC) trong các ứng dụng tiêu dùng mà người dùng không mong đợi
• Trải nghiệm người dùng không nhất quán: Các nền tảng khác nhau cung cấp các tùy chọn xác thực khác nhau cho cùng một tài khoản

Phù hợp nhất cho: Các ứng dụng ưu tiên tuân thủ tiêu chuẩn, môi trường doanh nghiệp với các loại trình xác thực đa dạng.

Cách tiếp cận này ưu tiên trải nghiệm người dùng bằng cách sửa đổi có chọn lọc các phương thức internal và hybrid dựa trên các mục tiêu tối ưu hóa cụ thể. Thay vì một quy tắc chung, hãy xem xét các kịch bản tối ưu hóa phổ biến sau:

Vấn đề: Các trình xác thực nền tảng iOS trả về mảng transport rỗng. Khi để trống hoặc được backend điền vào, người dùng có thể thấy các lời nhắc khóa bảo mật (USB, NFC) bên cạnh các tùy chọn nền tảng, gây nhầm lẫn trong các ứng dụng tiêu dùng.

Giải pháp: Đặt tường minh transports thành ["hybrid", "internal"] cho các trình xác thực nền tảng iOS. Điều này đảm bảo chỉ có xác thực nền tảng và các luồng đa thiết bị được đề xuất, ẩn đi các tùy chọn khóa bảo mật.

// Khi lưu trữ thông tin xác thực của trình xác thực nền tảng iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Kết quả: Giao diện người dùng xác thực gọn gàng không có lời nhắc khóa bảo mật cho các passkey được tạo trên iOS.

Vấn đề: Khi xác thực trên thiết bị di động, việc hiển thị mã QR để xác thực đa thiết bị tạo ra trải nghiệm người dùng kém—người dùng đã ở trên thiết bị di động và có sẵn passkey của họ.

Giải pháp: Xóa phương thức hybrid khi người dùng đang xác thực từ thiết bị di động, chỉ để lại ["internal"].

// Khi xây dựng allowCredentials để xác thực
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Kết quả: Người dùng di động chỉ thấy các tùy chọn xác thực trực tiếp mà không có các lời nhắc mã QR không cần thiết.

⚠️ Thận trọng: Việc tùy chỉnh transport không phải lúc nào cũng mang lại kết quả nhất quán trên các nền tảng. Kiểm thử thực tế cho thấy các tổ hợp trình duyệt và hệ điều hành xử lý transports khác nhau:

• Một số nền tảng hiển thị mã QR ngay cả khi hybrid bị loại trừ khỏi transports
• Một số khác ẩn mã QR ngay cả khi hybrid được bao gồm
• Hành vi thay đổi đáng kể giữa Chrome, Edge, Safari và Firefox trên Windows, macOS và iOS

Rủi ro đi vào ngõ cụt: Việc lọc transport quá nghiêm ngặt có thể tạo ra các ngõ cụt xác thực, nơi người dùng không thể đăng nhập được. Ví dụ, việc xóa hybrid có thể ngăn chặn các kịch bản xác thực đa thiết bị hợp lệ khi người dùng cần xác thực từ một thiết bị mượn. Luôn cung cấp các phương thức xác thực dự phòng và kiểm thử kỹ lưỡng trên các nền tảng mục tiêu của bạn trước khi triển khai tối ưu hóa transport.

Đây là những gợi ý tối ưu hóa: WebAuthn cung cấp các cơ chế khác để tối ưu hóa UX xác thực ngoài việc tùy chỉnh transport—chẳng hạn như hints.

Hành vi của transport khó lường: Xác thực đa thiết bị (CDA) thông qua phương thức hybrid có hành vi không nhất quán trên các tổ hợp trình duyệt và hệ điều hành. Kiểm thử thực tế cho thấy các giá trị transport không đảm bảo hành vi UI cụ thể—các nền tảng diễn giải và xử lý transports khác nhau, dẫn đến kết quả không mong đợi.

Sự phức tạp theo từng nền tảng: Khi kiểm soát tường minh các phương thức transport, bạn phải tính đến sự khác biệt của các nền tảng:

• iOS: Gửi mảng rỗng cho các trình xác thực nền tảng; yêu cầu điền vào
• Windows Hello: Phải giữ nguyên ["internal"]; thêm hybrid sẽ kích hoạt mã QR không mong muốn
• Web & Android: Thường cung cấp thông tin transport chính xác
• Biến thể CDA: Lời nhắc mã QR có thể xuất hiện hoặc biến mất bất kể sự hiện diện của hybrid trong mảng transports

Yêu cầu hiểu biết toàn diện: Kiểm soát tường minh các phương thức transport có nghĩa là bạn phải chịu trách nhiệm cho toàn bộ luồng. Bạn phải hiểu cách mỗi tổ hợp transport hoạt động trên tất cả các nền tảng mục tiêu và kiểm thử kỹ lưỡng. Việc tùy chỉnh transport có thể tạo ra các ngõ cụt xác thực, nơi không có đường dẫn xác thực hợp lệ nào cho người dùng.

Ưu điểm:

• UX tùy chỉnh: Kiểm soát chính xác các tùy chọn xác thực mà người dùng thấy trong các ngữ cảnh cụ thể
• Giải quyết vấn đề mảng rỗng của iOS: Định nghĩa tường minh các phương thức transport khi iOS không cung cấp
• Tối ưu hóa theo ngữ cảnh: Điều chỉnh UI xác thực dựa trên loại thiết bị

Nhược điểm:

• Hành vi khó lường: Việc tùy chỉnh transport không đảm bảo hành vi UI nhất quán—kiểm thử rộng rãi cho thấy các nền tảng diễn giải transports khác nhau, đôi khi hiển thị hoặc ẩn các tùy chọn bất kể giá trị transport
• Rủi ro ngõ cụt xác thực: Lọc transport quá nghiêm ngặt có thể ngăn người dùng xác thực hoàn toàn, đặc biệt là trong các kịch bản đa thiết bị
• Sai lệch so với đặc tả: Đi chệch khỏi các khuyến nghị của đặc tả, có khả năng gây ra sự cố với các thay đổi nền tảng trong tương lai
• Gánh nặng bảo trì: Yêu cầu logic và cập nhật liên tục cho từng nền tảng khi chúng phát triển
• Độ phức tạp: Phải xử lý thủ công các mảng rỗng của iOS, các ràng buộc của Windows Hello và các đặc thù khác của nền tảng
• Chi phí kiểm thử: Mọi quy tắc tối ưu hóa cần được xác minh trên tất cả các tổ hợp nền tảng

Phù hợp nhất cho: Các ứng dụng tiêu dùng có yêu cầu UX cụ thể, các nhóm có nguồn lực để duy trì logic dành riêng cho từng nền tảng, các kịch bản ưu tiên luồng xác thực được tinh giản hơn là tuân thủ nghiêm ngặt đặc tả.

Việc xử lý WebAuthn transport không tồn tại một cách độc lập—nó là một phần trong chiến lược triển khai passkey tổng thể của bạn. Hai cách tiếp cận phổ biến xuất hiện trong các triển khai thực tế, mỗi cách có những tác động khác nhau đối với việc sử dụng các phương thức internal và hybrid.

Cách tiếp cận này ưu tiên sự linh hoạt và tuân thủ tiêu chuẩn, cho phép người dùng xác thực bằng bất kỳ trình xác thực tương thích nào.

Đặc điểm triển khai:

• UI xác thực: Nút passkey xuất hiện cùng với các tùy chọn đăng nhập hiện có (tên người dùng/mật khẩu)
• allowCredentials: Đặt thành mảng rỗng [], cho phép bất kỳ thông tin xác thực nào cũng có thể khớp
• Các loại trình xác thực: Khóa bảo mật, xác thực đa thiết bị (mã QR), trình xác thực nền tảng đều được hỗ trợ
• Yêu cầu ứng dụng native: Phải hỗ trợ tất cả các phương thức xác thực, bao gồm cả khóa bảo mật
• preferImmediatelyAvailableCredentials: Không thể sử dụng, vì nó loại trừ khóa bảo mật và đăng nhập bằng mã QR theo định nghĩa
• Xử lý transport: Phải đáp ứng tất cả các loại transport, bao gồm cả các phương thức của khóa bảo mật (usb, nfc, ble)

Tác động đến Transport:

Với allowCredentials rỗng, các phương thức transport trở nên ít quan trọng hơn trong quá trình xác thực—nền tảng sẽ hiển thị tất cả các tùy chọn có sẵn. Tuy nhiên, điều này có nghĩa là người dùng có thể thấy các lời nhắc khóa bảo mật, mã QR và các tùy chọn nền tảng cùng một lúc, có thể gây ra sự phân vân trong các ứng dụng tiêu dùng.

Phù hợp nhất cho: Môi trường doanh nghiệp, các ứng dụng có lượng người dùng đa dạng yêu cầu hỗ trợ khóa bảo mật, các kịch bản ưu tiên sự linh hoạt tối đa trong xác thực.

Cách tiếp cận này tối ưu hóa cho UX người dùng phổ thông bằng cách hạn chế việc tạo passkey chỉ với các trình xác thực nền tảng và sử dụng các luồng ưu tiên định danh (identifier-first).

Đặc điểm triển khai:

• Tạo passkey: Chỉ cho phép các trình xác thực nền tảng thông qua authenticatorAttachment: "platform"
• Luồng xác thực: Ưu tiên định danh—người dùng nhập email/tên người dùng trước khi xác thực
• allowCredentials: Được điền với các thông tin xác thực cụ thể của người dùng (không rỗng) sau khi biết định danh
• Các loại trình xác thực: Trình xác thực nền tảng và xác thực đa thiết bị; khóa bảo mật thường bị loại trừ
• Tối ưu hóa ứng dụng native: Có thể sử dụng preferImmediatelyAvailableCredentials, loại trừ khóa bảo mật và xác thực đa thiết bị theo định nghĩa
• Xác thực đa thiết bị: Có sẵn trên web; không khả dụng khi sử dụng preferImmediatelyAvailableCredentials trong ứng dụng native, nhưng kịch bản này hiếm gặp (người dùng thường có passkey trên thiết bị họ đang sử dụng)
• Xử lý transport: Chỉ tập trung vào các phương thức internal và hybrid

Tác động đến Transport:

Vì allowCredentials chứa các thông tin xác thực cụ thể cùng với các phương thức transport của chúng, việc xử lý transport trở nên cực kỳ quan trọng.

Phù hợp nhất cho: Các ứng dụng tiêu dùng, ứng dụng di động native, các kịch bản ưu tiên UX được tinh giản hơn là sự linh hoạt của trình xác thực, các nền tảng đã có sẵn luồng ưu tiên định danh.

Đối với các nền tảng đã để lộ sự tồn tại của tài khoản hoặc sử dụng các luồng ưu tiên định danh (người dùng nhập email trước khi thấy các tùy chọn đăng nhập), cách tiếp cận tối ưu cho người dùng phổ thông phù hợp một cách tự nhiên. Một khi người dùng đã cung cấp định danh của họ:

1. Backend truy vấn các passkey hiện có
2. Trả về allowCredentials với các thông tin xác thực cụ thể và các phương thức transport của chúng
3. Nền tảng có thể tối ưu hóa UI xác thực dựa trên các phương thức transport
4. Không có rủi ro rò rỉ thông tin tài khoản bổ sung (định danh đã được cung cấp)

Trong những kịch bản này, các phương thức transport có thể trở thành một công cụ tối ưu hóa thay vì là một mối lo ngại về bảo mật. Bạn có thể tùy chỉnh các tùy chọn xác thực dựa trên ngữ cảnh thiết bị (di động so với máy tính) và khả năng của thông tin xác thực.

Khuyến nghị: Đối với các nền tảng đã sử dụng luồng ưu tiên định danh hoặc nơi rò rỉ thông tin tài khoản không phải là một vấn đề, cách tiếp cận tối ưu cho người dùng phổ thông với việc xử lý transport tường minh mang lại UX vượt trội, đặc biệt là trong các ứng dụng di động native nơi preferImmediatelyAvailableCredentials cho phép xác thực sinh trắc học liền mạch.

Bất kể bạn chọn cách tiếp cận nào để xử lý các phương thức internal và hybrid, hãy tuân theo các thực hành sau để giảm thiểu sự cố:

Lưu trữ Transports trong quá trình Đăng ký: Luôn lưu trữ mảng transports từ phản hồi của trình xác thực cùng với ID thông tin xác thực và khóa công khai. Dữ liệu này rất cần thiết cho các luồng xác thực.

Xử lý Mảng rỗng một cách linh hoạt: Khi nhận được một mảng transport rỗng từ các trình xác thực nền tảng iOS:

• Tuân thủ đặc tả: Để trống hoặc bỏ qua thuộc tính transports—có nghĩa là "bất kỳ phương thức nào" cũng được chấp nhận
• Cách tiếp cận tối ưu hóa: Điền vào ["internal", "hybrid"] để kiểm soát các tùy chọn xác thực được hiển thị

Kiểm thử trên tất cả các Nền tảng mục tiêu: Tạo một ma trận kiểm thử bao gồm tất cả các tổ hợp:

• Đăng ký: Web, iOS Native, Android Native
• Xác thực: Web, iOS Native, Android Native
• Xác minh mã QR xuất hiện khi mong đợi và bị ẩn khi không phù hợp

Hiểu sự khác biệt giữa Mảng rỗng và Thuộc tính bị thiếu: Cả mảng transports rỗng [] và thuộc tính transports bị thiếu thường được coi là "bất kỳ phương thức nào cũng được chấp nhận" theo đặc tả. Tuy nhiên, chi tiết triển khai khác nhau giữa các nền tảng.

Theo dõi các Thay đổi của Nền tảng: Các triển khai WebAuthn luôn phát triển. Apple, Google và Microsoft thường xuyên cập nhật hành vi của các trình xác thực của họ. Hãy cập nhật thông tin về những thay đổi có thể ảnh hưởng đến việc xử lý transport.

WebAuthn transports—đặc biệt là các phương thức internal và hybrid—là những chi tiết kỹ thuật có tác động thực tế đáng kể đến việc xác thực đa thiết bị. Chiến lược xử lý transport của bạn nên phù hợp với cách tiếp cận triển khai passkey rộng hơn và các nền tảng mục tiêu của bạn.

Quyết định về Transport nằm trong Chiến lược Rộng hơn: Cách bạn xử lý transports phụ thuộc vào việc bạn đang xây dựng cho sự linh hoạt tối đa (dùng allowCredentials rỗng) hay cho UX người dùng (ưu tiên định danh với thông tin xác thực cụ thể). Cách thứ hai làm cho transports trở nên quan trọng để tối ưu hóa.

Sự khác biệt giữa các Nền tảng đòi hỏi phải xử lý: Web và Android cung cấp thông tin transport đáng tin cậy, trong khi các trình xác thực nền tảng iOS trả về mảng rỗng. Windows Hello chỉ gửi ["internal"]. Hiểu rõ những khác biệt này là điều cần thiết cho việc triển khai thực tế.

Hai Cách tiếp cận Transport hợp lệ: Tuân thủ đặc tả (tin tưởng vào transports của trình xác thực) hoạt động tốt cho các kịch bản doanh nghiệp và linh hoạt tối đa. Kiểm soát tường minh (tối ưu hóa transports) phù hợp với các ứng dụng tiêu dùng có luồng ưu tiên định danh và các ứng dụng di động native.

Luồng ưu tiên Định danh cho phép Tối ưu hóa Transport: Khi người dùng cung cấp định danh của họ trước, việc xử lý transport trở thành một công cụ UX mạnh mẽ. Bạn có thể ngăn chặn mã QR không mong muốn trên di động, ẩn các tùy chọn khóa bảo mật và tinh giản việc xác thực—mà không có thêm lo ngại về rò rỉ thông tin tài khoản.

Đối với Doanh nghiệp / Linh hoạt Tối đa:

• Sử dụng allowCredentials rỗng để hỗ trợ tất cả các loại trình xác thực
• Tin tưởng vào các phương thức transport do trình xác thực cung cấp
• Chấp nhận rằng người dùng sẽ thấy nhiều tùy chọn xác thực hơn
• Triển khai đơn giản hơn, tương thích rộng hơn

Đối với Ứng dụng Tiêu dùng / Ứng dụng Native:

• Triển khai luồng xác thực ưu tiên định danh
• Hạn chế chỉ dùng các trình xác thực nền tảng (authenticatorAttachment: "platform")
• Sử dụng allowCredentials với thông tin xác thực cụ thể và các phương thức transport đã được tối ưu hóa
• Kích hoạt preferImmediatelyAvailableCredentials trong các ứng dụng native
• Điền vào các mảng rỗng của iOS bằng ["hybrid", "internal"]
• Lọc hybrid trên thiết bị di động để ngăn mã QR
• UX vượt trội với các tùy chọn xác thực được tinh giản

Đối với các Nền tảng đã có Luồng ưu tiên Định danh:

• Vấn đề rò rỉ thông tin tài khoản không còn đáng lo ngại
• Cách tiếp cận tối ưu cho người dùng phổ thông phù hợp một cách tự nhiên với UX hiện có
• Tối ưu hóa transport mang lại lợi ích UX ngay lập tức
• Cách tiếp cận được khuyến nghị cho hầu hết các ứng dụng tiêu dùng

Bắt đầu bằng cách tuân thủ đặc tả, sau đó tối ưu hóa dựa trên chiến lược của bạn:

1. Lưu trữ transports chính xác như nhận được trong quá trình đăng ký
2. Quyết định chiến lược tổng thể của bạn (linh hoạt tối đa so với tối ưu cho người dùng)
3. Nếu chọn tối ưu cho người dùng: triển khai luồng ưu tiên định danh và tối ưu hóa transports
4. Xử lý các mảng rỗng của iOS một cách phù hợp với chiến lược đã chọn
5. Kiểm thử kỹ lưỡng trên các nền tảng Web, iOS Native và Android Native

Bối cảnh WebAuthn vẫn tiếp tục phát triển. Các nhà cung cấp nền tảng thường xuyên cập nhật các triển khai của họ, và các đặc tả như WebAuthn Level 3 giới thiệu các khả năng mới. Xây dựng các hệ thống linh hoạt, điều chỉnh việc xử lý transport phù hợp với chiến lược xác thực rộng hơn của bạn sẽ đảm bảo việc triển khai passkey của bạn vẫn mạnh mẽ và mang lại trải nghiệm người dùng tuyệt vời khi hệ sinh thái trưởng thành.