Passkey năm 2026: Đâu thực sự là rào cản khiến áp dụng chậm?

Dùng passkey ngay bây giờ nếu người dùng của bạn đang trên iOS hoặc Android và bạn muốn ship trong quý này. Đợi lại nếu người dùng của bạn chủ yếu dùng Windows desktop hoặc đang trong phạm vi SSO của doanh nghiệp. Những rào cản này có thật và chưa có hướng giải quyết gần — còn những con số nổi bật từ Passkey Index của FIDO được lấy từ những deployment diễn ra tốt nhất, không phải rollout trung bình.

Bài viết này dành cho ai

Developer Node và Edge đang đánh giá passkey cho hệ thống auth production vào giữa năm 2026. Nếu bạn đã đi sâu vào một implementation SAML hoặc đang quản lý shared workstation trong môi trường doanh nghiệp, phần enterprise sẽ cho bạn biết điều gì đó cụ thể và đáng nản. Nếu bạn đang xây dựng công cụ cho người dùng cuối hoặc developer nhắm đến mobile, phần library và UX là nơi bạn sẽ tập trung thời gian.

Chúng tôi đã kiểm thử gì

Chúng tôi đánh giá simplewebauthn v13.3.0 so với @github/webauthn-json wrapper đã bị deprecated, kiểm thử browser support trên Chrome 135, Firefox 138, và Edge 134, đồng thời đối chiếu với FIDO Alliance Passkey Index (tháng 10 năm 2025) và thông báo 5 tỷ passkey của FIDO Alliance (tháng 5 năm 2026). Kiểm thử platform bao gồm iOS 18.4, Android 15, và Windows 11 24H2. Tỷ lệ auth thành công được tính theo phương pháp đo lường của FIDO Alliance áp dụng trên các deployment thử nghiệm có công cụ đo lường.

Kết quả đánh giá passkey

Lỗ hổng hệ sinh thái: câu chuyện về browser không như bạn nghĩ

Câu quảng cáo là “passkey hoạt động ở khắp nơi.” Firefox 138 không hỗ trợ Signal API và gần như không có Conditional Create. Edge 134 chỉ đạt 7% Conditional Create. Chrome thì ổn.

Conditional Create — tính năng trình duyệt lặng lẽ đề nghị tạo passkey trong lúc người dùng đăng nhập bằng mật khẩu thông thường, không cần màn hình đăng ký riêng — là thứ giúp passkey được áp dụng mà không cần nhiều nỗ lực. Nếu thiếu nó, bạn đang yêu cầu người dùng tự tìm trang cài đặt passkey trong phần cài đặt tài khoản, hiểu tại sao họ nên quan tâm, rồi click qua lời nhắc sinh trắc học. Hầu hết họ sẽ không làm vậy.

Tác động thực tế: nếu analytics của bạn cho thấy hơn 15% người dùng dùng Firefox hoặc Edge, tỷ lệ đăng ký passkey của bạn sẽ thấp và bạn sẽ không biết tại sao. Những người dùng đó âm thầm bỏ qua đăng ký và tiếp tục dùng mật khẩu. Bạn sẽ thấy tỷ lệ áp dụng thấp và đi debug UX trong khi vấn đề thực sự là khả năng của browser.

Trên mobile, câu chuyện ngược lại. iOS 18 và Android 15 đều đạt 85–95% tỷ lệ auth thành công với passkey. Touch ID, Face ID, và vân tay Android xử lý thao tác người dùng đáng tin cậy. QR handoff sang điện thoại cho các tình huống cross-device hoạt động tốt theo hướng đó.

Windows là nơi mọi thứ sụp đổ. Tỷ lệ auth thành công trên Windows 11 chỉ đạt 45–60%, và QR bridge sang điện thoại là bắt buộc trong 55–65% trường hợp. Đó không phải là trải nghiệm passkey — đó là QR code với thêm nhiều bước, và còn chậm hơn việc gõ mật khẩu. Windows Hello credential management là nguyên nhân gốc rễ, và việc sửa nó phụ thuộc vào lộ trình authenticator của Microsoft, không phải bất cứ điều gì trong tầm kiểm soát của bạn.

Lỗ hổng Signal API của Firefox quan trọng vì một lý do khác: Signal là extension cho phép browser phát hiện khi có passkey và hiển thị nó trong UI tự động. Thiếu nó, người dùng Firefox không có được conditional mediation flow nhắc nhở họ khi đăng nhập. Họ phải tự biết để tìm tùy chọn passkey. Trong thực tế, họ không làm vậy.

Độ chín của thư viện: lựa chọn đã được xác định

@github/webauthn-json đã được archive vào ngày 26 tháng 8 năm 2025. GitHub đã chuyển sang hướng khác. Nếu bạn đang dùng nó, hãy migrate.

simplewebauthn v13.3.0 có khoảng 1.5 triệu lượt download server mỗi tuần (npm). Nó xử lý toàn bộ WebAuthn ceremony: registration, authentication, CBOR decoding, attestation verification. Từ v8.0.0 nó chạy native trên Cloudflare Workers qua WebCrypto — không cần module crypto của Node.js, không cần polyfill. Nếu bạn đang đánh giá WebAuthn library năm 2026, lựa chọn thực tế đã được xác định.

API của thư viện này ổn định xuyên suốt từ v10 đến v13. Các hàm generateRegistrationOptions / verifyRegistrationResponse / generateAuthenticationOptions / verifyAuthenticationResponse bao gồm mọi flow phổ biến. Tài liệu hướng dẫn cấu hình RP ID, user verification, authenticator selection, và conditional mediation flow cho các browser hỗ trợ.

import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';

// Registration
const options = await generateRegistrationOptions({
  rpName: 'Your App',
  rpID: 'yourapp.com',
  userID: new TextEncoder().encode(user.id),
  userName: user.email,
  authenticatorSelection: {
    residentKey: 'required',
    userVerification: 'required',
  },
});

// Verification (after client response)
const verification = await verifyRegistrationResponse({
  response: credential,
  expectedChallenge: challenge,
  expectedOrigin: 'https://yourapp.com',
  expectedRPID: 'yourapp.com',
  requireUserVerification: true,
});

Các giải pháp hosted — Stytch và Clerk — đáng biết đến với team muốn tránh tự quản lý toàn bộ WebAuthn ceremony logic. Cả hai đều không có affiliate program được xác nhận, vì vậy không có lý do thương mại nào để đẩy bạn về phía họ. Chọn hosted nếu độ phức tạp vận hành quan trọng hơn chi phí và quyền kiểm soát. Chọn simplewebauthn nếu bạn muốn tự chủ UX và giữ auth surface trong hạ tầng của mình. Để so sánh chi tiết các thư viện WebAuthn hiện có, xem thư viện Passkey/WebAuthn tốt nhất cho Node.js năm 2026.

1Password tích hợp với passkey trên các browser và thiết bị. Với team mà nhân viên dùng môi trường hỗn hợp — một số trên Mac, một số trên Windows — passkey vault cross-platform của 1Password giảm bớt một phần vấn đề quản lý credential trên Windows mà không yêu cầu mỗi người dùng tự quản lý platform authenticator của mình.

Ngõ cụt về UX: mất thiết bị và thất bại trong truyền đạt khi đăng ký

Phản đối phổ biến nhất từ người dùng về passkey là “chuyện gì xảy ra khi tôi mất điện thoại.” Câu trả lời, với người dùng đã đăng ký qua iCloud Keychain hoặc Google Password Manager, là: không có gì tệ. Passkey của bạn đồng bộ qua các thiết bị và tồn tại sau khi mất phần cứng. Credential lưu trong cloud credential store, không phải trên phần cứng thiết bị.

Vấn đề là không có implementation WebAuthn tiêu chuẩn nào nói với người dùng điều này khi đăng ký. Flow mặc định của browser chỉ nói “tạo passkey” và yêu cầu thao tác sinh trắc học. Nó không nói “cái này đồng bộ với tài khoản iCloud của bạn và bạn sẽ không mất nếu đánh rơi điện thoại.” Người dùng không biết điều đó sẽ nghĩ passkey gắn với thiết bị. Khi họ có điện thoại mới hoặc mất điện thoại cũ, họ nghĩ họ đã mất quyền truy cập tài khoản và quay lại flow khôi phục mật khẩu — mà bạn vẫn phải duy trì dù sao, làm giảm giá trị của passkey mà bạn đã yêu cầu họ tạo.

Trên iOS và Android, hầu hết passkey lưu trong iCloud Keychain hoặc Google Password Manager — đồng bộ là mặc định, gắn với thiết bị là ngoại lệ. Đó là câu trả lời thực sự cho vấn đề mất thiết bị. Nhưng nó tạo ra sự phụ thuộc tập trung: độ tin cậy của bạn phụ thuộc một phần vào độ tin cậy của iCloud Keychain. Cho đến nay vẫn ổn. Nhưng sự tập trung là phụ thuộc hệ thống đáng biết đến.

FIDO Alliance Passkey Index (tháng 10 năm 2025) báo cáo 36% tài khoản đã đăng ký và 26% lần đăng nhập sử dụng passkey ở các deployment trưởng thành. Những con số đó trông tốt cho đến khi bạn đọc phương pháp: chúng được lấy từ các tổ chức đã chạy các chiến dịch truyền thông có cấu trúc trước, trong và sau khi ra mắt — mỗi tổ chức trong mẫu đều có chương trình đào tạo người dùng rõ ràng. Các dịch vụ bỏ qua truyền thông khi đăng ký hoàn toàn vắng mặt trong mẫu đó. Ship passkey không có touchpoint giải thích đăng ký và con số của bạn sẽ không giống index này chút nào.

FIDO Alliance báo cáo 5 tỷ passkey đang được sử dụng tích cực trên toàn cầu tính đến tháng 5 năm 2026. Đó là con số của cả hệ sinh thái. Dữ liệu deployment chi tiết hơn của FIDO (26% lần đăng nhập ở các deployment tốt nhất) thực dụng hơn trong vận hành, và nó đi kèm dấu sao “deployment tốt nhất”.

Cross-device passkey portability (CXP) đang được chuẩn hóa tại FIDO Alliance. Apple thông báo hỗ trợ import và export passkey cho iOS 26, iPadOS 26, macOS 26, và visionOS 26 tại WWDC 2025, xây dựng trên FIDO Alliance Credential Exchange Format (CXF) — passkey có thể export từ iCloud Keychain và import vào password manager của bên thứ ba tương thích. Đó là lộ trình portability đáng tin cậy đầu tiên trong hệ sinh thái. Nó không giúp ích cho người dùng đã đăng ký hai năm trước và đang chuyển ecosystem hôm nay, nhưng nó có nghĩa portability là vấn đề có thể giải quyết với hướng đi rõ ràng thay vì lo ngại lock-in vĩnh viễn.

Rào cản doanh nghiệp: shared workstation và sự không tương thích với SSO

Có hai mô hình doanh nghiệp chặn việc triển khai passkey một cách rõ ràng, và cả hai đều không có giải pháp trong tương lai gần.

Shared workstation chặn triển khai passkey trong bán lẻ, y tế, và sản xuất. Trong môi trường nhiều nhân viên dùng chung một terminal — điểm bán lẻ, trạm điều dưỡng trong y tế, terminal trên sàn sản xuất — credential binding model của WebAuthn sụp đổ. Một credential được gắn với authenticator trên một thiết bị cụ thể. Ba y tá dùng chung workstation có nghĩa là không ai trong số họ có thể đăng ký passkey cá nhân trên đó mà không xung đột với người khác. QR bridge hỗ trợ bước đăng nhập nhưng yêu cầu mỗi người dùng mang và sử dụng điện thoại cá nhân, điều này không phải là giả định đáng tin cậy trong những môi trường đó.

Sự không phù hợp về kiến trúc là sâu sắc. WebAuthn được thiết kế xung quanh mô hình một người dùng, một thiết bị, một credential store. Shared workstation đảo ngược điều đó. Có những workaround — roaming authenticator, FIDO2 security key mà nhân viên mang theo — nhưng chúng thêm chi phí phần cứng và overhead hỗ trợ mà hầu hết doanh nghiệp chưa sẵn sàng chấp nhận.

Enterprise SSO hiện tại về mặt kiến trúc không tương thích với passkey. Đây là rào cản ít rõ ràng hơn và có hậu quả nghiêm trọng hơn.

Enterprise SSO hoạt động bằng cách ủy quyền xác thực cho một Identity Provider — Okta, Azure Active Directory, Ping Identity. Browser của người dùng gửi thông tin xác thực đến IdP, IdP phát hành SAML assertion hoặc OIDC token, và app của bạn tin tưởng phán quyết của IdP. Passkey xác thực trực tiếp tại relying party — thiết bị của người dùng chứng minh sở hữu private key gắn với RP ID của app bạn. Hai flow này không kết hợp được mà không có proxy dịch WebAuthn assertion sang SAML assertion, và không có IdP lớn nào có proxy production-ready tính đến tháng 5 năm 2026.

Kết quả thực tế: nếu người dùng của bạn xác thực qua Okta hoặc Azure AD, bạn cần đường auth riêng biệt. Passkey cho tài khoản cá nhân trên auth riêng của app, SSO cho tài khoản doanh nghiệp. Điều đó có thể xây dựng được, nhưng nó nhân đôi auth surface của bạn, nhân đôi logic quản lý session, và tạo ra trải nghiệm người dùng phân kỳ tùy thuộc vào loại tài khoản mà người dùng có.

Một chú thích đáng đề cập: dashboard của Cloudflare không hỗ trợ passkey. Bạn có thể deploy simplewebauthn trên Cloudflare Workers, bảo vệ app người dùng bằng passkey, và đăng nhập vào Cloudflare dashboard bằng mật khẩu trong lúc làm vậy. Điều này không phải lý do để loại Cloudflare khỏi danh sách runtime — bản thân nền tảng Workers phù hợp tốt với WebAuthn — nhưng đây là lời nhắc nhở hữu ích rằng hỗ trợ passkey ở lớp tool vẫn đang bắt kịp với việc truyền bá passkey.

Kết luận

Triển khai passkey ngay bây giờ nếu người dùng của bạn chủ yếu trên iOS hoặc Android, bạn đang xây dựng công cụ cho người dùng cuối hoặc developer, và bạn sẵn sàng xây dựng UX đăng ký giải thích rõ ràng hành vi đồng bộ. simplewebauthn v13.3.0 trên runtime Node hoặc Edge là thư viện của bạn. Dành ngân sách cho một khoảnh khắc giáo dục người dùng đặc thù passkey khi đăng ký — một câu giải thích rằng passkey đồng bộ với tài khoản iCloud hoặc Google của họ giảm đáng kể lượng support ticket “tôi mất điện thoại”.

Đợi lại nếu hơn 20% người dùng của bạn đang trên Windows desktop mà không có điện thoại gần bên, bạn đang trong phạm vi enterprise SSO không có IdP hỗ trợ WebAuthn, hoặc bạn có các tình huống shared-workstation trong deployment. Những lỗ hổng nền tảng không nằm trong lộ trình giải quyết ngắn hạn. Nếu đây là trường hợp của bạn, Better Auth vs Clerk 2026 so sánh chi phí và độ phức tạp của các giải pháp hosted auth thay thế.

Về những con số: 36% đăng ký và 26% lượt đăng nhập tích cực là con số tốt nhất từ các tổ chức đã chạy chương trình truyền thông rollout có cấu trúc. Không có khoản đầu tư đó, con số của bạn sẽ chỉ là một phần nhỏ. Con số 5 tỷ passkey trên toàn cầu là đếm lượt sử dụng tích cực trên toàn hệ sinh thái của FIDO Alliance — xem nó như tín hiệu, không phải bằng chứng rằng deployment của bạn sẽ đạt mức tương tác tương tự.

Hệ sinh thái đang thực sự cải thiện. CXP portability có thật và có lộ trình. simplewebauthn đã trưởng thành và được duy trì tích cực. Hỗ trợ mobile platform vững chắc. Những rào cản còn lại — Firefox Conditional Create, độ tin cậy của Windows Hello, kiến trúc enterprise SSO — là thật và chuyển động chậm. Ship ở nơi nó hoạt động, đợi ở nơi nó không.

Lưu ý

Bài viết này bao gồm affiliate link đến 1Password. Chương trình trả 25% hoa hồng qua CJ Affiliate. 1Password không tham gia sản xuất bài viết này; các phán quyết ở trên là độc lập.
Chúng tôi không kiểm thử passkey flow trên macOS qua Chrome, Safari, và Firefox natively. Hành vi cross-browser trên macOS có thể khác với những gì chúng tôi mô tả cho Windows và mobile.
Phạm vi tỷ lệ auth thành công (85–95% mobile, 45–60% Windows) đến từ dữ liệu deployment có công cụ đo lường của FIDO Alliance. Con số của bạn sẽ thay đổi dựa trên tập người dùng, phân bố browser, và UX đăng ký.
Số liệu Passkey Index là từ tháng 10 năm 2025. Số passkey toàn cầu là từ thông báo tháng 5 năm 2026 của FIDO Alliance. Cả hai được tự báo cáo bởi các bên có lợi ích trong việc nêu bật sự tăng trưởng áp dụng.
Tính năng import/export passkey của Apple (chuyển credential dựa trên FIDO CXF) chưa được kiểm thử trong production.