Passkey và FIDO2/WebAuthn

1. Tổng quan

A. Định nghĩa

Passkey là thông tin xác thực không mật khẩu (Passwordless) dựa trên tiêu chuẩn FIDO2 (WebAuthn + CTAP), cho phép đăng nhập dịch vụ bằng cặp khóa công khai-khóa riêng lưu trên thiết bị của người dùng. Khóa riêng không rời khỏi vùng bảo mật của thiết bị (Secure Enclave·TPM, v.v.), dịch vụ chỉ đăng ký khóa công khai, và việc xác thực được thực hiện bằng cách dùng khóa riêng ký lên thử thách (challenge) sau khi mở khóa thiết bị (xác thực cục bộ) bằng sinh trắc học·PIN, v.v.

Passkey không phải tên của một sản phẩm cụ thể mà là tên gọi thân thiện với người tiêu dùng cho thông tin xác thực được tạo bởi bộ xác thực (authenticator) FIDO2 do FIDO Alliance và W3C tiêu chuẩn hóa. Nếu mật khẩu truyền thống là cách "chia sẻ với server một chuỗi bí mật mà người dùng biết", thì passkey là cách "tạo giá trị chữ ký bằng khóa riêng do thiết bị giữ và server xác minh bằng khóa công khai"; khác biệt bản chất là không tồn tại bí mật dùng chung (shared secret) trên mạng hay trên server.

B. Bối cảnh ra đời và sự cần thiết

Trong thống kê sự cố xác thực, phần lớn các vụ xâm phạm vẫn bắt nguồn từ mật khẩu. Do gánh nặng ghi nhớ, người dùng tái sử dụng cùng một mật khẩu cho nhiều dịch vụ, tạo mảnh đất cho credential stuffing (nhồi thông tin đăng nhập) — rò rỉ ở một nơi lan sang dịch vụ khác. Ngoài ra, mật khẩu về bản chất dễ bị phishing (lừa đảo giả mạo). Khi trang giả mạo lừa người dùng nhập mật khẩu, từ góc nhìn server không thể phân biệt với đăng nhập hợp lệ. Dù bổ sung xác thực thứ hai bằng OTP·SMS, phishing AiTM (Adversary-in-the-Middle) chặn và chuyển tiếp mã theo thời gian thực cùng tấn công mệt mỏi MFA (fatigue) làm người dùng kiệt sức vẫn vượt qua được.

Những giới hạn này xuất phát từ thuộc tính cấu trúc "bí mật dùng chung" của mật khẩu. Vì người dùng·server·(đôi khi) kẻ trung gian phải biết cùng một giá trị, giá trị đó có thể bị đánh cắp bất cứ lúc nào trong quá trình truyền·lưu·nhập lại. Dù server lưu mật khẩu dưới dạng băm, khi rò rỉ vẫn trở thành mục tiêu bẻ khóa ngoại tuyến, và các vụ rò rỉ hàng loạt cứ lặp lại. Passkey là nỗ lực loại bỏ tận gốc nhóm vấn đề này bằng cách xóa bỏ chính bí mật dùng chung. Khóa riêng không bao giờ được truyền đi nên rò rỉ server chẳng có gì để lấy, và giá trị xác thực được gắn (binding) với một tên miền cụ thể nên trên trang giả mạo, chữ ký thậm chí không được tạo ra.

Về mặt chính sách, NIST SP 800-63B của Mỹ đưa phương tiện xác thực có khả năng kháng phishing (phishing resistance) làm yêu cầu của cấp độ bảo đảm cao nhất (AAL3), và các Big Tech chủ chốt (Apple·Google·Microsoft) đã tích hợp sẵn passkey vào hệ điều hành·trình duyệt·tài khoản trong giai đoạn 2022~2024. Nhờ đó, passkey đã vượt qua giai đoạn công nghệ thử nghiệm và bước vào giai đoạn trở thành phương tiện đăng nhập tiêu chuẩn của các dịch vụ đại chúng.

2. Cấu trúc tổng thể và thành phần

FIDO2 về cơ bản gồm hai đặc tả. Một là WebAuthn (tiêu chuẩn W3C) — API JavaScript giữa ứng dụng web và trình duyệt; hai là CTAP2 (Client to Authenticator Protocol) — giao thức truyền thông giữa trình duyệt·hệ điều hành (nền tảng) và bộ xác thực ngoài (khóa bảo mật·điện thoại). Hai đặc tả này ăn khớp với nhau, để dịch vụ web có thể yêu cầu xác thực dựa trên khóa công khai theo cùng một cách, bất kể hình thái vật lý của bộ xác thực.

flowchart LR
    User["Người dùng"] -->|"Xác thực cục bộ sinh trắc·PIN"| AUTH["Bộ xác thực (Authenticator)"]
    AUTH -->|"CTAP2"| CLIENT["Client (trình duyệt·OS)"]
    CLIENT -->|"WebAuthn API"| RP["RP (server dịch vụ web)"]
    subgraph KEY["Vùng bảo mật thiết bị (Secure Enclave·TPM)"]
      PRIV["Khóa riêng (không thể rò rỉ ra ngoài)"]
    end
    AUTH --- KEY
    RP -.->|"Lưu khóa công khai·xác minh chữ ký"| DB[("Kho thông tin xác thực")]

Giải thích các thành phần từ góc độ nguyên lý như sau. RP (Relying Party) là dịch vụ web yêu cầu đăng nhập; khi đăng ký thì lưu khóa công khai và định danh thông tin xác thực của người dùng, khi đăng nhập thì xác minh chữ ký. Client là trình duyệt và hệ điều hành, nhận lời gọi WebAuthn API và giao tiếp với bộ xác thực qua CTAP2, đóng vai trò trung gian cốt lõi của khả năng kháng phishing bằng cách chuyển chính xác thông tin tên miền (origin) yêu cầu cho bộ xác thực. Bộ xác thực là chủ thể tạo·lưu khóa riêng và thực hiện ký, được chia thành bộ xác thực nền tảng tích hợp trong thiết bị (vân tay·khuôn mặt trên điện thoại, Windows Hello trên PC, v.v.) và bộ xác thực chuyển vùng (ngoài) kết nối qua USB·NFC (khóa bảo mật như YubiKey).

Cơ chế quyết định giúp bảo mật passkey được thiết lập là khóa riêng không rời khỏi vùng bảo mật phần cứng. Phép ký được thực hiện bên trong vùng bảo mật và chỉ kết quả đi ra ngoài; để khởi động phép tính này, xác thực cục bộ (sinh trắc·PIN) của người dùng phải được thực hiện trước. Do đó, dù thiết bị bị đánh cắp vật lý, không mở khóa thì không thể tạo chữ ký, và hai yếu tố "sở hữu (thiết bị)" và "sinh trắc/tri thức (mở khóa)" kết hợp một cách tự nhiên.

3. Quy trình xác thực — đăng ký và xác thực

Hoạt động của passkey cần được hiểu qua hai giai đoạn đăng ký (Registration/Attestation) và xác thực (Authentication/Assertion). Đăng ký là quá trình lần đầu cài khóa công khai vào dịch vụ, còn xác thực là quá trình ở mỗi lần đăng nhập sau đó, dùng khóa riêng ký lên challenge do server đưa ra để chứng minh danh tính.

sequenceDiagram
    participant U as Người dùng
    participant C as Client(trình duyệt·OS)
    participant A as Bộ xác thực
    participant S as Server RP
    Note over U,S: Giai đoạn đăng ký
    S->>C: Gửi challenge·thông tin RP·thông tin người dùng
    C->>A: Yêu cầu create()(kèm origin)
    U->>A: Xác thực cục bộ sinh trắc·PIN
    A->>A: Tạo cặp khóa(khóa riêng giữ trong vùng bảo mật)
    A->>C: Khóa công khai·ID thông tin xác thực·chữ ký(attestation)
    C->>S: Yêu cầu đăng ký khóa công khai
    S->>S: Xác minh rồi lưu khóa công khai·credentialID
    Note over U,S: Giai đoạn xác thực
    S->>C: Gửi challenge ngẫu nhiên
    C->>A: Yêu cầu get()(kèm origin)
    U->>A: Xác thực cục bộ sinh trắc·PIN
    A->>A: Ký challenge bằng khóa riêng(assertion)
    A->>C: Trả về giá trị chữ ký
    C->>S: Chuyển chữ ký
    S->>S: Xác minh chữ ký bằng khóa công khai → đăng nhập thành công

Ở giai đoạn đăng ký, server gửi cho client challenge ngẫu nhiên, thông tin tên miền của mình (RP ID) và thông tin định danh người dùng. Client gọi navigator.credentials.create() và đồng thời chuyển origin thực tế đang truy cập. Bộ xác thực xác nhận xác thực cục bộ của người dùng, rồi tạo cặp khóa dành riêng cho dịch vụ đó; khóa riêng được giữ lại trong vùng bảo mật, còn khóa công khai·ID thông tin xác thực·(tùy chọn) chứng thực nguồn gốc bộ xác thực (attestation) được trả về. Server xác minh các giá trị này và gắn khóa công khai vào tài khoản người dùng.

Ở giai đoạn xác thực, server mỗi lần đều phát hành challenge mới, và tính ngẫu nhiên này là cốt lõi ngăn chặn tấn công phát lại (replay attack), vì chữ ký bắt được trước đó không hợp lệ với challenge khác. Bộ xác thực dùng khóa riêng ký gộp "challenge + thông tin origin + bộ đếm chữ ký", và server xác minh bằng khóa công khai đã lưu. Ở đây, gắn với origin tạo nên khả năng kháng phishing. Passkey người dùng đăng ký tại bank.com được gắn với RP ID bank.com, nên tại tên miền giả như bank-login.com có bề ngoài giống hệt, trình duyệt chuyển một origin khác, và bộ xác thực ngay từ đầu không tạo ra chữ ký hợp lệ. Người dùng có bị lừa thì giao thức cũng không bị lừa.

Mặt khác, nhiều bộ xác thực cung cấp kèm bộ đếm chữ ký (signature counter) tăng lên mỗi lần ký. Nếu server phát hiện bộ đếm nhỏ hơn hoặc bằng giá trị trước đó thì có thể nghi ngờ bộ xác thực bị sao chép (cloning), nên được dùng làm phương tiện phát hiện sao chép bộ xác thực phần cứng.

4. Các loại — passkey đồng bộ và passkey gắn cố định với thiết bị

Passkey được chia thành hai loại theo khả năng di chuyển của khóa riêng, và sự phân biệt này quyết định sự đánh đổi giữa mức bảo đảm an ninh và tính tiện lợi khi sử dụng.

Passkey đồng bộ (Synced Passkey) là dạng khóa riêng được mã hóa rồi sao chép·đồng bộ tới nhiều thiết bị thông qua tài khoản đám mây như Apple iCloud Keychain, Google Password Manager. Dù mua điện thoại mới, người dùng chỉ cần khôi phục tài khoản đăng nhập là passkey đi theo, nên đạt được tiện lợi lớn là mất thiết bị không đồng nghĩa với mất tài khoản. Đổi lại, vì khóa riêng di chuyển trong hệ sinh thái đám mây, ranh giới tin cậy của bảo mật mở rộng từ từng phần cứng riêng lẻ sang tài khoản đám mây và thủ tục khôi phục của nó. Tức là bảo mật của chính tài khoản đám mây trở thành tuyến phòng thủ cuối cùng.

Passkey gắn cố định với thiết bị (Device-bound Passkey) là dạng khóa riêng tuyệt đối không rời khỏi một thiết bị cụ thể, như khóa bảo mật phần cứng YubiKey. Nguy cơ sao chép·rò rỉ trên thực tế không có nên phù hợp cho nơi cần cấp độ bảo đảm cao nhất như chính phủ·tài chính·tài khoản quản trị doanh nghiệp, nhưng khi mất thiết bị thì không thể khôi phục thông tin xác thực đó, nên bắt buộc phải vận hành theo cách đăng ký nhiều bộ xác thực làm dự phòng.

Bảng dưới đây so sánh hai loại này với phương tiện xác thực truyền thống, nhưng chỉ riêng bảng thì không thấy được tiêu chí lựa chọn, nên phần ngữ cảnh được giải thích ngay sau.

Phân loại	Passkey đồng bộ	Passkey gắn cố định thiết bị	Mật khẩu+OTP
Di chuyển khóa riêng	Đồng bộ qua đám mây	Không thể ra ngoài thiết bị	Không áp dụng (bí mật dùng chung)
Khả năng kháng phishing	Cao (gắn origin)	Cao (gắn origin)	Thấp (AiTM có thể vượt qua)
Ứng phó mất thiết bị	Tự động kế thừa qua khôi phục tài khoản	Bắt buộc khóa dự phòng	Thủ tục đặt lại
Phạm vi phù hợp	Dịch vụ tiêu dùng đại chúng	Bảo đảm cao (quản trị·tài chính)	Hệ thống cũ nói chung

Cốt lõi của lựa chọn là "tiện lợi khôi phục vs quyền kiểm soát khóa riêng". Với dịch vụ đại chúng, việc người dùng rời bỏ (bị khóa tài khoản) chính là chi phí nên passkey đồng bộ là thực tế, còn tài khoản đặc quyền có thiệt hại khổng lồ khi bị xâm phạm thì hợp lý hơn khi dùng passkey gắn cố định thiết bị để tối đa hóa quyền kiểm soát. Trong thực tế, khuyến nghị thiết kế áp dụng phân cấp hai loại theo mức rủi ro của tài khoản.

5. Chuyên sâu — quan hệ với hệ thống xác thực hiện có và chiến lược triển khai

Cần phân biệt rằng passkey không thay thế OAuth 2.0·OIDC mà tăng cường cửa ngõ đầu tiên là xác thực người dùng của chúng. Nếu OIDC xử lý bài toán xác thực liên kết (federation) "truyền an toàn cho dịch vụ khác biết ai đã đăng nhập", thì passkey thay đổi phương tiện xác thực chính thực sự xác thực người dùng tại IdP (Identity Provider) đó từ mật khẩu sang chữ ký khóa công khai. Trên thực tế, các IdP lớn áp dụng passkey làm cách đăng nhập và phát hành kết quả dưới dạng token OIDC.

Từ góc độ triển khai, thách thức thực tế lớn nhất là chuyển đổi dần dần và khôi phục tài khoản. Không thể chuyển người dùng dựa trên mật khẩu hiện có chỉ sau một đêm, nên thường dùng cách tiếp cận từng bước: (1) sau khi đăng nhập bằng mật khẩu thì khuyến khích đăng ký passkey, (2) các lần đăng nhập sau ưu tiên đề xuất passkey nhưng vẫn giữ mật khẩu làm phụ trợ. Vấn đề là khi đó nếu còn đường khôi phục yếu như đặt lại qua mật khẩu hay SMS thì toàn bộ bảo mật bị hạ xuống mức đó. Bởi vì kẻ tấn công thay vì chọc thủng trực diện passkey mạnh sẽ nhắm vào cửa sau "quên mật khẩu". Vì vậy, đường khôi phục cũng phải được thiết kế lại theo hướng kháng phishing bằng nhiều passkey·thiết bị đã xác minh·mã khôi phục ngoại tuyến, v.v. thì mới đạt hiệu quả thực sự.

Trong môi trường doanh nghiệp, chính sách chứng thực nguồn gốc (Attestation) để xác minh độ tin cậy của bộ xác thực là quan trọng. Ngành chịu quản lý có thể yêu cầu attestation để chỉ cho phép bộ xác thực phần cứng đáp ứng tiêu chuẩn xác thực nhất định (ví dụ: chứng nhận FIPS), nhưng điều này khiến người dùng không dùng được thiết bị tùy ý, làm giảm tiện lợi và gây lo ngại về thông tin cá nhân (định danh mẫu thiết bị). Ngược lại, dịch vụ đại chúng không yêu cầu attestation, chấp nhận mọi bộ xác thực để giảm ma sát khi triển khai. Như vậy, mức yêu cầu attestation là đòn bẩy chính sách quyết định điểm cân bằng giữa bảo mật·tiện lợi·quyền riêng tư.

6. Lưu ý và hàm ý

Từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), việc triển khai passkey không phải là thay đổi giao diện đăng nhập đơn thuần mà phải được tiếp cận như thiết kế lại kiến trúc xác thực và chiến lược quản lý rủi ro.

Chiến lược áp dụng (triển khai từng bước·phân cấp): Tiếp cận dựa trên rủi ro thay vì chuyển đổi toàn diện. Chính sách phân cấp theo hạng tài khoản là thực tế: người dùng thông thường dùng passkey đồng bộ để bảo đảm tiện lợi, còn tài khoản đặc quyền như quản trị·tài chính bắt buộc khóa phần cứng gắn cố định thiết bị. Trong giai đoạn cùng tồn tại với hệ thống cũ, nên thu hẹp dần mật khẩu thay vì loại bỏ hoàn toàn.
Đánh đổi (bảo mật vs khả năng khôi phục): Càng khóa chặt khóa riêng trong thiết bị càng an toàn nhưng khó khôi phục khi mất; càng đồng bộ lên đám mây càng tiện lợi nhưng ranh giới tin cậy chuyển sang tài khoản đám mây. Đặc biệt, để đường khôi phục không trở thành mắt xích yếu nhất, cần thiết kế đồng thời việc đăng ký nhiều bộ xác thực dự phòng và thủ tục khôi phục kháng phishing. Cần cảnh giác với sai lầm đặt cửa sau yếu cho cửa chính mạnh.
Triển vọng (tương lai không mật khẩu): Nhờ được tích hợp sẵn trong các hệ điều hành·trình duyệt chủ chốt, passkey được dự báo sẽ lan rộng thành phương tiện đăng nhập tiêu chuẩn, và cùng với yêu cầu kháng phishing của cơ quan quản lý sẽ mở rộng sang lĩnh vực tài chính·công. Tuy nhiên, tính di động đa nền tảng (chuyển passkey giữa các hệ sinh thái khác nhau) và tiêu chuẩn hóa khôi phục tài khoản vẫn là thách thức còn lại để phổ cập.
Công nghệ liên kết và quản trị: Passkey đóng vai trò trục xác minh danh tính mạnh của Zero Trust (không tin cậy mặc định), và hiệu quả đạt tối đa khi kết hợp với MFA·phát hiện hành vi bất thường·đánh giá độ tin cậy thiết bị. Khi triển khai, cần thiết kế tích hợp từ góc độ quản trị bao gồm đánh giá tác động thông tin cá nhân (thông báo rõ rằng thông tin sinh trắc chỉ được xử lý trong thiết bị và không được truyền tới server), chính sách kiểm soát truy cập và hệ thống ghi nhật ký kiểm toán.

Tài liệu tham khảo

W3C, "Web Authentication: An API for accessing Public Key Credentials (WebAuthn)" — https://www.w3.org/TR/webauthn-2/
FIDO Alliance, "Passkeys (Passwordless Authentication)" — https://fidoalliance.org/passkeys/
NIST, "SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management" — https://pages.nist.gov/800-63-3/sp800-63b.html

Tóm tắt một câu: Passkey là xác thực không mật khẩu dựa trên FIDO2 (WebAuthn+CTAP), đặt khóa riêng trong vùng bảo mật thiết bị và đăng nhập bằng chữ ký khóa công khai gắn với tên miền, ngăn chặn tận gốc phishing·credential stuffing·rò rỉ server; tuy nhiên việc lựa chọn loại đồng bộ hay gắn cố định thiết bị và thiết kế đường khôi phục quyết định thành bại.