Các loại WebAuthn Transport: Internal và Hybrid

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

Nhận whitepaper

Lưu ý: Theo đặc tả WebAuthn, chuỗi transport trống có nghĩa là thông tin transport không khả dụng hoặc bị giữ lại vì mục đích quyền riêng tư. Thường được các trình duyệt hiểu là mọi transport đều có thể khả thi.

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

• Bạn nên xử lý WebAuthn transport như thế nào, đặc biệt là internal và hybrid transport, để đảm bảo trải nghiệm xác thực liên thiết bị tối ưu?

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

Bài viết này xem xét cách các WebAuthn transport 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ý internal và hybrid transport-mỗi cách đều có những ưu nhược điểm riêng.

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

1. WebAuthn transport: 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ả vs. xử lý tối ưu cho internal và hybrid transport
3. Các phương pháp hay nhất và đề xuất triển khai xác thực liên thiết bị

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

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ư YubiKey hoặc các token bảo mật FIDO2 khác.

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

ble: Tạo điều kiện cho việc xác thực qua Bluetooth Low Energy (Năng lượng thấp), 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 liên thiết bị, điển hình là khi người dùng quét mã QR để xác thực trên các thiết bị-chẳng hạn như sử dụng điện thoại để xác thực trên trình duyệt máy tính để bàn hoặc ngược lại. Transport này có thể kích hoạt lời nhắc mã QR trên cả thiết bị di động và máy tính để bàn, điều này có thể 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 bên trong chính thiết bị-như iCloud Keychain (được 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 thiết bị Android. Đây là các trình xác thực nền tảng (platform authenticators).

Khi passkey được tạo, trình xác thực sẽ báo hiệu các transport mà nó hỗ trợ. Thông tin này được gửi đến relying party (backend của bạn), bộ phận này 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, relying party sẽ gửi các transport này trở lại máy khách trong danh sách allowCredentials, giúp trình duyệt hoặc nền tảng xác định phương thức xác thực nào sẽ được cung cấp cho người dùng.

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

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 quá trình 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 cung cấp dữ liệu transport thay đổi dựa trên trình xác thực bên dưới:

Trình xác thực nền tảng (Platform authenticators): Windows Hello chỉ cung cấp ["internal"], phản ánh tính 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ó sẽ cung cấp ["internal", "hybrid"] vì Google Password Manager hỗ trợ xác thực liên thiết bị qua Điện thoại Android.

Khóa bảo mật phần cứng (Hardware security keys): Cung cấp các transport 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ộ đá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à liên thiết bị.

Thông tin này luân chuyển một cách đáng tin cậy trong các ngữ cảnh web, mặc dù các transport 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: Đặc tả W3C WebAuthn

API Credential Manager của Android hoạt động tương tự như trình duyệt web. Khi tạo passkey trong ứng dụng Android native, Credential Manager cung cấp thông tin transport phản ánh hành vi của 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 cậy vào thông tin này mà không cần xử lý đặc biệt.

Tài liệu: Android Credential Manager

iOS thể hiện một tình huống phức tạp hơn. Framework AuthenticationServices của Apple xử lý transport theo các cách 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, được xác minh qua Face ID hoặc Touch ID): Thường trả về mảng transport trống trong quá trình tạo passkey. Điều này cho thấy thông tin transport không khả dụng hoặc bị giữ lại vì quyền riêng tư-theo đặc tả WebAuthn, các user agent có thể trả về các chuỗi trống khi không biết thông tin transport hoặc để bảo vệ quyền riêng tư. Các relying party nên coi các transport như các gợi ý thay vì là những đảm bảo.

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, tuân theo mẫu được mong đợi.

Tài liệu: Apple AuthenticationServices

Dữ liệu production thực tế từ các ứng dụng web và native tiết lộ các mẫu transport sau, được sắp xếp theo tần suất. Lưu ý rằng các phân phối này bị ảnh hưởng bởi các chi tiết cụ thể về triển khai và đặc điểm nhân khẩu học của máy khách (sử dụng thiết bị di động so với máy tính để bàn, tính khả dụng của các ứng dụng native), nhưng chúng cung cấp thông tin chi tiết có giá trị về việc sử dụng transport thông thường:

Thông tin chi tiết chính:

Trình xác thực nền tảng thống trị: Phần lớn các passkey sử dụng transport internal, thường kết hợp với hybrid để hỗ trợ xác thực liên thiết bị. Điều này phản ánh sự tập trung của người tiêu dùng vào các trình xác thực nền tảng (iCloud Keychain, Google Password Manager).

Mảng trống rất phổ biến: Các ứng dụng iOS native thường trả về các mảng transport trống cho các trình xác thực nền tảng, đại diện cho một phần đáng kể thông tin xác thực trên production. Như đã thảo luận trong phần 2.2.3, điều này cho thấy thông tin transport không khả dụng chứ không phải là hỗ trợ transport toàn diện.

Khóa bảo mật rất hiếm: Khóa bảo mật phần cứng (usb, nfc) chỉ chiếm một tỷ lệ rất nhỏ trong các passkey trên production, cho thấy việc sử dụng chúng chủ yếu trong môi trường doanh nghiệp hoặc các kịch bản bảo mật cao thay vì các ứng dụng cho người tiêu dùng.

Tồn tại các biến thể về thứ tự: Thứ tự các transport trong mảng (["internal", "hybrid"] vs ["hybrid", "internal"]) thay đổi tùy theo nền tảng và cách triển khai trình xác thực nhưng không có sự khác biệt về mặt chức năng - cả hai đều biểu thị khả năng hỗ trợ cho cùng một phương thức transport.

Thuật ngữ kế thừa: Định danh transport cable đôi khi xuất hiện trong các triển khai cũ và đồng nghĩa với hybrid (caBLE = cloud-assisted Bluetooth Low Energy, tên ban đầu cho hybrid transport).

Sự phân phối này củng cố tầm quan trọng của việc xử lý chính xác internal và hybrid transport, vì chúng chiếm đại đa số các triển khai passkey trong thế giới thực.

Tính khả dụng của transport cho thấy những gì trình xác thực báo cáo, không phải là luồng kết quả có hoàn thành hay không. Phân tích tỷ lệ hoàn thành xác thực liên thiết bị của Corbado Passkey Benchmark 2026 đo lường mức độ hoàn thành hybrid-transport trong Quý 1 năm 2026 ở mức 60–78% trên web Windows và 66–86% trên web macOS nói chung, được chia thành 79–98% (Win) / 83–98% (macOS) cho các yêu cầu trên cùng một thiết bị so với 52–67% (Win) / 59–76% (macOS) cho các luồng ưu tiên định danh. Hãy coi hybrid là transport có chi phí cao nhất trong logic định tuyến và ưu tiên các luồng giữ người dùng trên thiết bị đang giữ thông tin xác thực.

Cùng một trình xác thực thường báo cáo các mẫu transport khác nhau dựa trên nền tảng, phiên bản và ngữ cảnh triển khai. Sự thay đổi này là bình thường và đã được lường trước:

iCloud Keychain thể hiện ba mẫu:

• ["internal", "hybrid"] - Phổ biến nhất, thường từ trình duyệt web
• [] (mảng trống) - Rất phổ biến, từ các ứng dụng iOS native
• ["hybrid", "internal"] - Ít phổ biến hơn, thay đổi thứ tự
• Chỉ riêng ["internal"] hoặc ["hybrid"] - Các trường hợp biên hiếm gặp

Google Password Manager cho thấy sự biến đổi nhiều nhất:

• ["hybrid", "internal"] - Mẫu phổ biến nhất
• ["internal", "hybrid"] - Thứ tự thay thế phổ biến
• ["internal", "cable"] - Cài đặt cũ (cable = thuật ngữ cũ cho hybrid)
• [] (mảng trống) - Từ một số ngữ cảnh native nhất định
• Các transport đơn lẻ hiếm khi xảy ra

Windows Hello là nhất quán nhất:

• ["internal"] - Mẫu thống trị (được thiết kế để gắn với thiết bị)

Các trình quản lý mật khẩu như 1Password, Bitwarden, Dashlane, và LastPass đều có các mẫu biến đổi tương tự:

• Cả hai thứ tự ["internal", "hybrid"] và ["hybrid", "internal"]
• Mảng trống [] từ bối cảnh ứng dụng native
• Đôi khi chỉ là ["internal"]

Samsung Pass (hệ sinh thái Android) chủ yếu sử dụng:

• ["hybrid", "internal"] và ["internal", "hybrid"] - Cả hai thứ tự đều phổ biến

Sự khác biệt về nền tảng: Cùng một trình xác thực hoạt động khác nhau trên web so với native, iOS so với Android hoặc Windows so với macOS.

Sự phát triển của phiên bản: Việc báo cáo transport đã phát triển theo thời gian. Các phiên bản cũ hơn có thể sử dụng cable thay vì hybrid, hoặc báo cáo các tổ hợp khác nhau.

Lựa chọn triển khai: Một số trình xác thực ưu tiên internal trước, số khác lại ưu tiên hybrid. Thứ tự không có tác động chức năng nhưng khác nhau tùy theo cách triển khai.

Tính nhạy cảm với ngữ cảnh: Các ứng dụng native, đặc biệt là trên iOS, thường nhận được mảng trống ngay cả từ các trình xác thực có báo cáo transport đầy đủ trong bối cảnh web.

Điểm chính cần nhớ: Đừng cho rằng các mảng transport sẽ nhất quán cho một trình xác thực nhất định. Thiết kế quá trình triển khai của bạn để xử lý tất cả các biến thể một cách linh hoạt, tập trung vào sự hiện diện của các transport cụ thể thay vì đối sánh chính xác các mảng.

Các nhà phát triển phải đối mặt với một sự lựa chọn: tuân theo nghiêm ngặt đặc tả, hoặc tối ưu hóa internal và hybrid transport để mang lại trải nghiệm người dùng tốt hơn. Mỗi phương pháp đều có điểm mạnh và hạn chế.

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

Thực hiện: Khi một passkey được tạo, lưu 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 các transport chính xác này vào 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 khả năng 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 cho khóa bảo mật phần cứng (YubiKey, v.v.), những thiết bị 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 việc cung cấp 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 credential Windows Hello

Nhược điểm:

• Hành vi mảng trống của iOS: Các trình xác thực nền tảng trên iOS trả về transport trống, điều này cho thấy thông tin transport không có sẵn-các nền tảng có thể diễn giải điều này khác nhau khi xác định các tùy chọn xác thực để hiển thị
• 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 người dùng, nơi chúng không được 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

Tốt nhất cho: Ứng dụng ưu tiên sự 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 internal và hybrid transport 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 của iOS trả về mảng transport trống. Khi để trống hoặc được điền bởi backend, người dùng có thể thấy các lời nhắc khóa bảo mật (USB, NFC) cùng với các tùy chọn nền tảng, gây nhầm lẫn trong các ứng dụng dành cho người tiêu dùng.

Giải pháp: Thiết lập rõ ràng transport 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ác xác thực nền tảng và luồng liên thiết bị được cung cấp, ẩn đi các tùy chọn khóa bảo mật.

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

Kết quả: UI xác thực sạch sẽ mà 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 liên thiết bị tạo ra UX kém-người dùng đã ở trên một thiết bị di động có sẵn passkey của họ.

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

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

Kết quả: Người dùng thiết bị 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 thao tác 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. Thử nghiệm mở rộng cho thấy các tổ hợp trình duyệt và HĐH xử lý transport 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 transport
• Những nền tảng 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: Lọc transport quá hạn chế 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 chút nào. Ví dụ: việc xóa hybrid có thể ngăn cản các kịch bản xác thực liên thiết bị hợp pháp 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 tra 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 các tối ưu hóa transport.

Đây là các 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 thao tác transport-chẳng hạn như hints.

Hành vi transport không thể đoán trước: Xác thực liên thiết bị (CDA) qua transport hybrid thể hiện hành vi không nhất quán giữa các tổ hợp trình duyệt và HĐH. Thử nghiệm thực tế chứng minh rằng các giá trị transport không đảm bảo hành vi giao diện người dùng cụ thể-các nền tảng diễn giải và xử lý transport theo cách 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 cụ thể: Khi kiểm soát rõ ràng các transport, bạn phải tính đến sự khác biệt của nền tảng:

• iOS: Gửi mảng trố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 chỉ là ["internal"]; việc thêm hybrid sẽ kích hoạt các 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: Các 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 transport

Yêu cầu hiểu biết toàn diện từ đầu đến cuối: Việc kiểm soát rõ ràng các transport có nghĩa là 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 của mình và kiểm tra kỹ lưỡng. Thao tác với transport có thể tạo ra các ngõ cụt xác thực mà ở đó không có con đường xác thực hợp lệ nào tồn tại cho người dùng.

Ưu điểm:

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

Nhược điểm:

• Hành vi không thể đoán trước: Thao tác transport không đảm bảo hành vi giao diện người dùng nhất quán-thử nghiệm mở rộng cho thấy các nền tảng diễn giải transport khác nhau, đôi khi hiển thị hoặc ẩn các tùy chọn bất kể giá trị transport
• Nguy cơ gặp ngõ cụt xác thực: Lọc transport quá hạn chế có thể ngăn cản người dùng xác thực hoàn toàn, đặc biệt trong các kịch bản liên thiết bị
• Đi chệch khỏi đặc tả: Chệch khỏi các khuyến nghị đặc tả, có khả năng gây ra sự cố với các thay đổi của nền tảng trong tương lai
• Gánh nặng bảo trì: Yêu cầu logic cập nhật liên tục cụ thể theo nền tảng khi các nền tảng phát triển
• Độ phức tạp: Phải xử lý thủ công các mảng trống của iOS, các ràng buộc của Windows Hello và các điểm đặ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

Tốt nhất cho: Ứng dụng tiêu dùng có yêu cầu UX cụ thể, đội ngũ có nguồn lực để duy trì logic theo nền tảng, kịch bản ưu tiên tối ưu quy trình xác thực hơn là việc tuân thủ khắt khe các tiêu chuẩn.

Xử lý WebAuthn transport không tồn tại độc lập-đây là một phần trong chiến lược triển khai passkey tổng thể của bạn. Hai phương pháp phổ biến nổi lên trong việc triển khai thực tế, mỗi phương pháp có hàm ý khác nhau đối với việc sử dụng internal và hybrid transport.

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

Đặc điểm Thực hiện:

• Giao diện 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ó (username/password)
• allowCredentials: Được đặt thành mảng trống [], cho phép bất kỳ credential nào đều khớp
• Loại trình xác thực: Tất cả khóa bảo mật, xác thực liên thiết bị (mã QR), trình xác thực nền tảng đều được hỗ trợ
• Yêu cầu đối với Ứng dụng Native: Phải hỗ trợ mọi phương pháp xác thực, bao gồm cả khóa bảo mật
• preferImmediatelyAvailableCredentials: Không thể sử dụng, vì định nghĩa của nó loại trừ khóa bảo mật và đăng nhập bằng mã QR
• Xử lý Transport: Phải phù hợp với mọi loại transport, bao gồm cả transport của khóa bảo mật (usb, nfc, ble)

Ảnh hưởng của Transport:

Với allowCredentials trống, 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ả tùy chọn có sẵn. Tuy nhiên, điều này đồng nghĩa với việc người dùng có thể thấy lời nhắc khóa bảo mật, mã QR và tùy chọn nền tảng cùng một lúc, gây bối rối trong các ứng dụng hướng đến người tiêu dùng.

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

Phương pháp này tối ưu hóa trải nghiệm cho người dùng bằng cách giới hạn việc tạo passkey đối với 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 Thực hiện:

• Tạo Passkey: Các lời nhắc hướng tới người dùng (ví dụ như sau khi đăng nhập, luồng tạo tự động) sử dụng authenticatorAttachment: "platform" để tập trung vào các trình xác thực có sẵn ngay lập tức
• Hỗ trợ Khóa Bảo mật: Sẵn có qua cài đặt tài khoản web mà không có hạn chế authenticatorAttachment, cho phép những người dùng nâng cao (power users) chọn bất kỳ trình xác thực nào, bao gồm khóa bảo mật
• Luồng Xác thực: Ưu tiên định danh-người dùng nhập email/username trước khi xác thực
• allowCredentials: Điền sẵn danh sách các credential cụ thể của người dùng (không để trống) sau khi xác định được danh tính
• Loại Trình xác thực: Ưu tiên trình xác thực nền tảng và xác thực liên thiết bị; hỗ trợ khóa bảo mật nhưng không khuyến khích trong các luồng chính
• Tối ưu Hóa ứng dụng Native: Sử dụng preferImmediatelyAvailableCredentials để xác thực ẩn (silent), ngay lập tức mà không có lời nhắc nhập khóa bảo mật hoặc quét mã QR
• Xác thực Liên thiết bị: Sẵn có trên web; cố ý bị loại trừ trong ứng dụng native khi sử dụng preferImmediatelyAvailableCredentials (người dùng thường xác thực trên chính thiết bị lưu trữ passkey của họ)
• Xử lý Transport: Chủ yếu tập trung vào các transport internal và hybrid

Ảnh hưởng của Transport:

Vì allowCredentials chứa các credential cụ thể đi kèm các transport tương ứng, việc xử lý transport trở nên cực kỳ quan trọng trong việc tối ưu hóa trải nghiệm xác thực.

Thực tế Về Khóa Bảo mật: Khóa bảo mật chiếm một phần rất nhỏ trong việc sử dụng passkey ở các hệ thống người tiêu dùng quy mô lớn-chủ yếu là cho những người dùng nâng cao hoặc những người có yêu cầu bảo mật cụ thể. Cách tiếp cận chú trọng người tiêu dùng thừa nhận thực tế này bằng cách vẫn hỗ trợ khóa bảo mật nhưng không tối ưu hóa các luồng chính dựa trên chúng.

Chiến lược Tạo Hai Tầng: Triển khai có thể cân bằng tính tương thích của khóa bảo mật và UX được tối ưu hóa thông qua hai con đường tạo khóa:

• Gợi ý và Lời nhắc Người dùng: Lời nhắc sau đăng nhập và quy trình tự động tạo sử dụng authenticatorAttachment: "platform", hướng dẫn người dùng sử dụng passkey khả dụng ngay lập tức với tỉ lệ thành công cao
• Cài đặt Tài khoản Web: Cung cấp tùy chọn tạo không có authenticatorAttachment, cho phép người dùng nâng cao sử dụng khóa bảo mật, trình quản lý mật khẩu của bên thứ ba, hoặc bất kỳ trình xác thực nào khác

Mô hình này xuất hiện trong các hệ thống lớn: khóa bảo mật hoạt động trong phần cài đặt, nhưng gợi ý tới người dùng thì được tối ưu hóa cho trường hợp sử dụng chính yếu - những trình xác thực nền tảng cung cấp khả năng xác thực ẩn, lập tức.

Tốt nhất cho: Ứng dụng người tiêu dùng, ứng dụng native di động, những trường hợp ưu tiên UX mượt mà thay vì tính linh hoạt của trình xác thực, các nền tảng có các luồng ưu tiên định danh sẵn có.

Đối với những nền tảng làm rò rỉ việc tồn tại của tài khoản hoặc sử dụng 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 nhắm vào người tiêu dùng phù hợp một cách tự nhiên. Một khi người dùng cung cấp định danh:

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à 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 transport
4. Không tạo thêm rủi ro dò tìm tài khoản (vì danh tính đã được cung cấp)

Trong các tình huống này, transport có thể trở thành công cụ tối ưu hóa thay vì rủi ro bảo mật. Bạn có thể tùy chỉnh các tùy chọn xác thực dựa vào bối cảnh thiết bị (di động vs máy tính để bàn) 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 vốn đã có luồng ưu tiên định danh, hoặc nơi rò rỉ tài khoản không phải là vấn đề, phương pháp tập trung vào người tiêu dùng với việc quản lý rõ ràng transport giúp cải thiện giao diện (UX) vượt trội, đặc biệt đối với các ứng dụng di động native, nơi preferImmediatelyAvailableCredentials mang lại trải nghiệm xác thực sinh trắc học liền mạch.

Dù bạn chọn cách nào để xử lý internal và hybrid transport, hãy làm theo các phương pháp này để giảm thiểu sự cố:

Lưu Transport Trong Khi Đăng Ký: Luôn lưu giữ mảng transports nhận từ phản hồi của trình xác thực bên cạnh ID và public key của thông tin xác thực. Dữ liệu này cần thiết cho các quy trình xác thực.

Xử Lý Mảng Trống Một Cách Khéo Léo: Khi nhận được mảng transport trống từ trình xác thực nền tảng iOS:

• Tuân thủ theo tiêu chuẩn: Cứ để trống hoặc bỏ đi thuộc tính transport-điều này cho biết thông tin về transport không có sẵn; nền tảng sẽ tự quyết định các tùy chọn có thể.
• Phương pháp tối ưu hóa: Gán bằng ["internal", "hybrid"] để kiểm soát các tùy chọn xác thực được hiển thị

Chiến Lược Transport Cho Web vs. Native: Phân biệt cách quản lý theo bối cảnh:

• Xác thực web: Gộp mọi transport, nhằm hỗ trợ nhiều trình xác thực hơn, kể cả khóa bảo mật thông qua USB/NFC
• Xác thực ứng dụng native: Sử dụng preferImmediatelyAvailableCredentials cho xác thực ẩn; các transport được gửi dựa trên trạng thái đã lưu
• Các trang Cài đặt/Quản lý: Hỗ trợ toàn bộ trình xác thực dành cho đối tượng power user

Xử lý Xác thực Bằng Khóa Bảo Mật: Khi người dùng đã đăng ký các khóa bảo mật:

• Web: Xác định transport của khóa trong các credential lưu giữ và chắc chắn quy trình xác thực đáp ứng được chúng
• Ứng dụng Native: Tính toán cung cấp phương pháp xác thực dự phòng hoặc hướng dẫn người dùng tới web để dùng khóa bảo mật
• Phương pháp Hybrid: Ứng dụng native tập trung cho trình xác thực nền tảng, còn web vẫn giữ độ linh hoạt tối đa cho mọi trình xác thực

Thử nghiệm Khắp Các Nền Tảng Mục Tiêu: Cần lập bảng thử nghiệm gồm tất cả tổ hợp:

• Đăng ký: Web, iOS Native, Android Native
• Xác thực: Web, iOS Native, Android Native
• Đảm bảo cơ chế xác thực ẩn vẫn chạy với preferImmediatelyAvailableCredentials
• Xác nhận khóa bảo mật sử dụng được trong phần cài đặt không có authenticatorAttachment
• Đảm bảo mã QR chỉ hiện đúng chỗ, đúng ngữ cảnh

Hiểu Rõ Ngữ Nghĩa Của Transport: Thấy rõ khác biệt giữa mảng transport trống với thiếu thuộc tính transport:

• Mảng transport trống []: Chỉ ra rằng thông tin transport không có hoặc bị giấu đi do vấn đề riêng tư. Các user agent sẽ đưa ra dãy rỗng nếu không thể/không muốn báo cáo năng lực. Đây không có nghĩa "mọi transport được hỗ trợ"-hãy xem như gợi ý khi thông tin vắng mặt.
• Thiếu thuộc tính transports: Khi transport bị lược bỏ khỏi thuộc tính của thông tin xác thực, user agent xác định cách thức xác thực bằng những nhân tố khác. Bối cảnh cực kỳ quan trọng: ứng dụng có những kết quả không giống nhau ở phần trả về sau khi đăng ký vs các tuỳ chọn ở yêu cầu xác thực.
• Gợi ý transport: Theo tiêu chuẩn, hãy xem các transport chỉ là mẹo (hints) hướng dẫn user agent tối ưu trải nghiệm (UI) xác thực, chứ không phải đảm bảo thẩm quyền khả năng thực thi.

Theo Dõi Các Thay Đổi Của Nền Tảng: Việc triển khai WebAuthn phát triển không ngừng. Apple, Google và Microsoft thường xuyên cập nhật cách hoạt động của trình xác thực. Hãy liên tục cập nhật các biến đổi liên quan tới quản lý transport.

WebAuthn transport-đặc biệt là internal và hybrid transport-là những chi tiết kỹ thuật có ảnh hưởng thực tế lớn tới việc xác thực liên thiết bị. Cách chiến lược vận dụng transport của bạn phải khớp với cách triển khai passkey nói chung và các nền tảng hướng tới.

Quyết Định Transport Là Thuộc Trong Chiến Lược Lớn Hơn: Cách bạn xử lý transport tuỳ vào việc phát triển để linh hoạt hết cỡ (để allowCredentials trống) hay tính đến UX của người tiêu dùng (ưu tiên định danh và dùng các thông tin xác thực cụ thể). Với phần sau, vai trò tối ưu hóa của transport rất trọng yếu.

Khác Biệt Nền Tảng Đòi Hỏi Sự Quản Lý: Web và Android thông báo chính xác về transport, thế nhưng trình xác thực nền tảng iOS trả lại mảng trống. Windows Hello duy nhất truyền về ["internal"]. Nhận biết rõ các khác biệt đó đặc biệt then chốt trong môi trường production.

Hai Hướng Tiếp Cận Transport Phù Hợp: Tuân thủ tiêu chuẩn (tin dùng transport từ trình xác thực) mang tác dụng cao ở phía doanh nghiệp và cho phép linh hoạt. Kiểm soát rõ ràng (tối ưu hoá transport) sẽ thỏa mãn những ứng dụng dân dụng với luồng ưu tiên định danh cũng như ứng dụng di động native.

Luồng Ưu tiên Định danh Kích hoạt Khả năng Tối ưu hóa Transport: Một khi người dùng khai báo định danh lúc đầu, việc kiểm soát transport thành một vũ khí UX mạnh mẽ. Bạn sẽ phòng trừ được việc mã QR nổi lên điện thoại vô ích, lấp tuỳ chọn dùng khoá bảo mật, rút gọn thao tác đăng nhập-không phải phiền lòng khi dò tìm tài khoản.

Dành Cho Doanh nghiệp / Linh Hoạt Tuyệt Đối:

• Để trống mảng allowCredentials nhằm bảo trợ mọi dòng trình xác thực
• Uỷ thác vào transport mà trình xác thực cho phép
• Bằng lòng với việc người dùng được chiêm ngưỡng đa dạng tùy chọn đăng nhập
• Dễ dàng xây dựng, tương thích sâu rộng

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

• Áp dụng các luồng ưu tiên định danh
• Các hướng dẫn của người dùng (sau đăng nhập, lời mời chào tự động): Cài authenticatorAttachment: "platform" nhằm tạo trải nghiệm xác thực ngay lập tức đạt tỉ lệ thành công cao
• Tại mục tài khoản web: Cho thiết lập khi không xài authenticatorAttachment hỗ trợ nhóm power user mong muốn mã/khoá an ninh (security key)
• Truyền allowCredentials đầy đủ với các thông tin xác thực cụ thể và transport đã điều chỉnh
• Các app Native: Chạy lệnh preferImmediatelyAvailableCredentials thực hiện đăng nhập ngầm/ẩn
• Thay thế mảng rỗng của iOS với cấu hình ["hybrid", "internal"]
• Xác thực qua web: Gộp bao hàm những loại transport tính luôn khóa mật khẩu (security keys)
• Bỏ bớt hybrid đối với dế cưng để ngưng hiển thị mã QR sai mục đích
• Vượt xa sự tưởng tượng bằng phương án cải thiện tiện ích trong khi không thay đổi tính hòa hợp (compatibility)

Dành Cho Những Cơ Sở Có Sẵn Các Luồng Ưu Tiên Định Danh:

• Sự cố lọt dữ liệu (account enumeration) không thành bận tâm nữa
• Chiến thuật hướng tới dân chúng ăn nhập tự nhiên vào trải nghiệm vốn có
• Tối ưu hóa Transport đưa luôn các thành quả UX thấy rõ
• Hướng tiếp cận nên được đề xuất ở nhiều ứng dụng dân dụng

Bắt đầu với tuân thủ tiêu chuẩn, kế tiếp tối ưu bám sát chiến lược:

1. Lưu giữ các transport chính xác với thời điểm thu được ngay tại khâu đăng ký
2. Chốt lại quyết định cuối (linh động nhất hay vì khách hàng)
3. Khi bạn muốn hướng mục tiêu dân sinh: Lắp tính năng ưu tiên định danh và cải biến transport
4. Xử lý chuẩn xác các mảng rỗng ở iOS tuỳ vào giải pháp đưa ra
5. Thực nghiệm trọn vẹn ở Web, iOS Native cùng với Android Native

Sân chơi WebAuthn biến hoá liên tục. Nhà bán phát triển thi thoảng tái cấu trúc bộ nhận diện. Cộng thêm các tài liệu Đặc tả WebAuthn Level 3 công bố thêm vô vàn thuộc tính mới. Do vậy khi hệ thống mềm dẻo khớp theo kế hoạch đã dự kiến sẽ đảm bảo tính ứng dụng passkey bền vững và dọn đường tận hưởng trọn vẹn tính tiện nghi trong lúc cả khối hạ tầng tiếp tục hoàn thiện.

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 →

iOS AuthenticationServices giấu nhẹm thông tin transport từ những trình xác thực nền tảng như iCloud Keychain, và trả mảng rỗng chiếu theo đặc quyền tính riêng tư về chỉ thị WebAuthn. Khóa bảo mật đối với iOS ngược lại nạp vào giá trị transport chẳng hạn ["usb"] hoặc ["nfc"]. Relying party do vậy nên đón nhận mọi transport chỉ như dữ liệu mách nước, hơn là lấy ra đảm bảo hoàn hảo năng lực khả thi.

cable là từ lóng lạc hậu đồng nghĩa với hybrid, nó viết tắt cho caBLE (cloud-assisted Bluetooth Low Energy). Hai thuật ngữ vẽ nên xác nhận ở các thiết bị dị biệt chẳng hạn khi rọi mã quét QR hoàn tất phiên PC bằng điện thoại. hybrid trở thành cách gọi chuẩn chỉ xuất hiện vào WebAuthn Level 3 nên vận dụng vào những cài đặt nâng cấp hơn.

Đới với các app dân sự đang tích hợp hệ thống ưu tiên định danh, hãy ấn định rạch ròi các transport thành ["hybrid", "internal"] với dạng trình xác thực nền tảng iOS gửi về mảng rỗng trong lúc tạo lập. Giải pháp này ngắt thông báo khoá thiết bị USB và NFC khỏi lộ diện phía giao diện của xác nhận. Còn phương thức hợp đúng quy cách (spec-compliant) kia chỉ định chừa trống array hoặc vứt hẳn mảng transport đó qua một bên.

Lấy transport hybrid ra lúc ở mobile sẽ bít việc hiện bảng quét mã QR giả như người truy cập vốn dùng ngay trên phương tiện mang các khoá passkey trong tay. Mặc dầu vậy, chơi đùa qua mặt các transport nảy sinh một cơ số biểu hiện trái tính: vài nền tảng thả mã QR lộ liễu kể khi hybrid bị đuổi khỏi hệ thống, nhiều hãng khác chôn giấu nó ở bất kỳ trạng huống nào. Chắc cú nhất là tra khảo kỹ lưỡng qua đủ các mặt trận nền tảng cùng dự trù giải pháp cứu rỗi (fallback) đề phòng làm lỡ đường lối người vô.

Khởi tạo mảng allowCredentials trống bao phủ trọn vẹn các giống hình trình xác thực gồm có khoá bảo mật và xác nhận liên thiết bị, mặc dầu thế làm tụt tính liên quan tại transport và thỉnh thoảng đem lại cùng lúc ngổn ngang quá nhiều lựa chọn cho người sử dụng. Bằng cách cài đặt nó kết nối với dữ liệu tài khoản cụ thể, việc quản lý transport trở thành vô cùng tất yếu hỗ trợ tăng cường thẩm mỹ (UI), đẩy luồng ưu tiên định danh (identifier-first) thanh trừng mã QR di động cùng thu giấu thông báo khóa cứng qua những trải nghiệm thông thường của khách hàng.