Passkeys & WebAuthn 2026 - Thay thế Password với FIDO2, Platform Authenticator và Phishing-resistant Auth trên .NET 10 và Vue

Posted on: 4/17/2026 8:11:33 AM

1. Vì sao năm 2026 là năm password thật sự bắt đầu chết

Suốt hai thập kỷ, password luôn là "lớp mỏng" mà mọi hệ thống đều kêu ca nhưng không ai thay thế được. Người dùng đặt mật khẩu yếu, tái sử dụng giữa các dịch vụ, lưu trong file Excel; đội bảo mật ép phải có ký tự đặc biệt, ép phải đổi sau 90 ngày, ép phải thêm OTP qua SMS — và kết quả là vẫn có credential stuffing, phishing, SIM-swap và account takeover tràn lan. Năm 2022 khi Apple, Google, Microsoft công bố cùng ủng hộ passkey, hầu hết kỹ sư vẫn coi đó là "một lớp tiện ích". Đến 2026, câu chuyện đã khác hẳn: các OS lớn mặc định đồng bộ passkey qua cloud keychain, trình duyệt đồng loạt bật Conditional UI, và hàng loạt nền tảng lớn (Google, Apple, Microsoft, GitHub, PayPal, Shopify, Amazon, các ngân hàng châu Âu) đã cho phép đăng nhập mà không cần biết password nữa. Cuối Q1 2026, FIDO Alliance công bố hơn 20 tỷ passkey đã được tạo trên thiết bị người dùng — vượt qua tổng số tài khoản kích hoạt 2FA qua SMS trước đó.

Đối với kỹ sư backend và frontend, chuyển sang passkey không chỉ là "thêm một phương thức login" — nó là cơ hội hiếm hoi để thiết kế lại toàn bộ luồng xác thực theo nguyên tắc phishing-resistant, loại bỏ hoàn toàn hạng mục "chia sẻ mật khẩu qua email", và cắt giảm chi phí vận hành đội support khoảng 60–70% cho các incident dạng "quên mật khẩu". Bài viết này là một cẩm nang thực chiến cho team đang cân nhắc triển khai passkey trên stack .NET 10 (Fido2NetLib) và Vue 3.6 (SimpleWebAuthn browser): từ thuật toán, luồng giao thức, chi tiết implement, strategy migration cho base người dùng đã có password, đến monitoring và checklist production.

2. Hành trình tiến hoá — Từ password tới passkey

WebAuthn không xuất hiện đột ngột. Nó là kết quả của hơn một thập kỷ thử sai: HOTP/TOTP, push notification OTP, smart card, U2F security key, FIDO UAF, rồi mới đến FIDO2. Hiểu lịch sử giúp bạn hiểu tại sao một số khái niệm trong spec có vẻ phức tạp — chúng mang dấu vết của những lỗi bảo mật cụ thể đã từng xảy ra.

3. Kiến trúc tổng thể — Relying Party, Authenticator và Client

Trước khi đọc code, hãy có sẵn trong đầu ba vai chính của mô hình. Thiếu một vai trong tư duy sẽ khiến bạn đọc spec rất mệt và dễ implement sai phần verify.

• Relying Party (RP) — backend của bạn. Khi sản phẩm có domain example.com, RP ID mặc định chính là domain đó. RP là bên phát hành challenge và bên xác thực chữ ký trả về.
• Authenticator — nơi nắm giữ private key. Có hai loại: platform authenticator (Touch ID/Face ID trên máy, Windows Hello, Android biometric) và roaming authenticator (Yubikey, Titan key, hoặc điện thoại kết nối qua hybrid transport).
• Client — trình duyệt (Chrome, Safari, Firefox, Edge) hoặc mobile OS. Client triển khai Web Authentication API, đóng vai trò cầu nối giữa JavaScript của bạn và authenticator.

flowchart LR
    U[Nguoi dung] --> C[Browser / Client]
    C <-- WebAuthn API --> A[Authenticator
Touch ID / Yubikey]
    C <-- HTTPS --> RP[Relying Party
.NET 10 API]
    RP <-- FMDS v3 --> FM[FIDO Metadata Service
Attestation trust]
    RP --> DB[(Credential Store
Postgres / SQL)]

Private key không bao giờ rời authenticator. Điều này tạo ra hệ quả rất lớn: backend không thể "lấy ra và đưa cho device khác" như với password hash — mỗi device/passkey là một credential độc lập có public key riêng, dù cùng chung một tài khoản. Hiểu được điều này là bước đầu tiên để thiết kế schema lưu trữ đúng.

4. Luồng Registration — "Tạo passkey" diễn ra như thế nào

Registration là luồng đầu tiên mà bạn implement và cũng là luồng hay sai nhất. Mô tả nguyên tắc rồi ta đi vào từng bước kỹ thuật.

sequenceDiagram
    participant U as User
    participant V as Vue frontend
    participant R as .NET RP API
    participant B as Browser
    participant A as Authenticator

    U->>V: Click "Tao passkey"
    V->>R: POST /webauthn/register/options
    R->>R: Sinh challenge 32 bytes,
luu vao session/cache
    R-->>V: PublicKeyCredentialCreationOptions
    V->>B: navigator.credentials.create(options)
    B->>A: CTAP makeCredential
    A->>U: Xac minh sinh trac hoc / PIN
    U-->>A: Touch / Face / PIN
    A-->>B: attestationObject + clientDataJSON
    B-->>V: PublicKeyCredential
    V->>R: POST /webauthn/register/verify
    R->>R: Verify signature, origin, challenge,
RP ID hash, user handle
    R->>DB: Luu CredentialId + PublicKey
+ SignCount + AAGUID
    R-->>V: 201 Created

Có năm điểm ở phía RP mà bạn bắt buộc phải kiểm tra, không được bỏ qua:

1. Challenge khớp: giá trị challenge trong clientDataJSON phải bằng đúng giá trị bạn đã sinh và lưu lại (lưu trong session/Redis/Memory cache với TTL ~5 phút).
2. Origin khớp: origin trong clientDataJSON phải nằm trong danh sách origin hợp lệ (thường chỉ là domain chính; với Single Page App có subdomain riêng cần cấu hình cẩn thận).
3. RP ID hash: 32 byte đầu của authenticatorData là SHA-256 của RP ID. Nếu không khớp — reject. Đây chính là lớp chống phishing "không thể bypass bằng social engineering".
4. Flag UP/UV: bit User Presence (UP) phải bật; với tài khoản cần xác thực mạnh, bit User Verification (UV) cũng nên bật (tương ứng yêu cầu sinh trắc/PIN khi đăng ký).
5. Attestation: nếu bạn yêu cầu attestation trực tiếp (direct), phải xác minh chuỗi X.509 dựa trên FIDO Metadata Service v3 để biết AAGUID tương ứng có phải authenticator được cấp chứng chỉ không.

5. Luồng Authentication — "Đăng nhập bằng passkey"

Authentication nhẹ hơn registration: không còn attestation, chỉ còn challenge + chữ ký. Nhưng có một cái bẫy mọi người hay mắc là quên kiểm tra sign counter hoặc implement sai Conditional UI.

sequenceDiagram
    participant U as User
    participant V as Vue frontend
    participant R as .NET RP API
    participant B as Browser
    participant A as Authenticator

    U->>V: Mo trang dang nhap
    V->>R: POST /webauthn/assert/options
    R-->>V: PublicKeyCredentialRequestOptions
    V->>B: navigator.credentials.get({mediation: "conditional"})
    B->>U: Hien autofill passkey trong o email
    U-->>B: Chon passkey, touch / face
    B->>A: CTAP getAssertion
    A-->>B: signature + authenticatorData + clientDataJSON
    B-->>V: AssertionResponse
    V->>R: POST /webauthn/assert/verify
    R->>R: Load public key theo credentialId,
verify signature,
kiem tra signCount tang
    R-->>V: 200 OK + session cookie / JWT
    V->>U: Vao ung dung

Điểm khác biệt lớn của Conditional UI so với "modal lo bật bấm login": browser xử lý picker bằng UI quen thuộc (autofill dropdown), và nếu không có passkey nào match thì nó lặng im — user vẫn có thể gõ email/mật khẩu như thường. Nhờ vậy bạn không phá UX của nhóm user chưa migrate.

6. Tại sao passkey chống phishing — phân tích ở tầng giao thức

Nhiều bài viết nói "passkey chống phishing" mà không giải thích vì sao. Lý do gọn ghẽ: chữ ký được bind vào RP ID, và authenticator chỉ ký khi client cung cấp RP ID đúng với lúc tạo. Hãy so sánh với OTP để thấy rõ.

Cột cuối giải thích vì sao FIDO Alliance gọi passkey là "phishing-resistant by design": không còn thao tác nào của user có thể bị "mượn tay" cho phisher. Tất cả đòn phòng thủ nằm trong giao thức, không phụ thuộc user có tỉnh táo hay không.

7. Platform Authenticator vs Roaming Authenticator

Chọn sai loại authenticator cho sản phẩm là nguyên nhân hàng đầu làm cho tỉ lệ adopt thấp. Một quy tắc đơn giản giúp bạn quyết định:

Cho sản phẩm consumer B2C, hãy ưu tiên platform authenticator (authenticatorAttachment: "platform" khi gọi registration) và dùng roaming key chỉ như phương án thứ hai cho user có nhu cầu bảo mật cao. Với sản phẩm enterprise, nhiều nhóm bắt buộc roaming key vì policy compliance — lúc đó bạn nên tổ chức đăng ký hai key (primary + backup) cho mỗi nhân viên.

8. Passkey Sync — Cloud keychain hoạt động ra sao

Điểm tranh cãi lớn nhất giữa team bảo mật "khó tính" và team sản phẩm là passkey sync. Về lý thuyết thuần tuý, passkey nên là device-bound (bind cứng vào 1 thiết bị). Nhưng thực tế năm 2022 chứng minh: nếu không sync, user mất điện thoại là mất tài khoản — trải nghiệm quá tệ. Do vậy Apple, Google, Microsoft đều triển khai synced passkey.

flowchart TB
    subgraph DeviceA["iPhone cua user"]
        PA[Passkey A
Secure Enclave]
    end
    subgraph DeviceB["MacBook cua user"]
        PB[Passkey A ban sao
Secure Enclave]
    end
    subgraph iCloud["iCloud Keychain"]
        Sync[E2EE sync tunnel
User recovery key required]
    end
    PA -- wrap bang E2EE --> Sync
    Sync -- unwrap tai thiet bi --> PB
    RP[Relying Party backend] <-- cung 1 credentialId --> PA
    RP <-- cung 1 credentialId --> PB

Từ góc nhìn RP, synced passkey là một credential xuất hiện trên nhiều device — không phải mỗi device một credential. Điều này đơn giản hoá schema lưu trữ nhưng cũng đồng nghĩa rằng nếu user rơi vào iCloud của mình, ai đó có thể login được. Đây là lý do các tài khoản mức "nhạy cảm cao" (ngân hàng, admin tenant) nên vẫn dùng device-bound hoặc roaming key chứ không dựa hoàn toàn vào synced passkey.

9. Thiết kế schema lưu credential trên RP

Cột lưu đúng là nền móng, sai là phải migrate đau đớn. Đây là schema tối thiểu mà bạn nên có ngay ngày đầu:

CREATE TABLE WebAuthnCredential (
    Id               BIGINT IDENTITY PRIMARY KEY,
    UserId           BIGINT       NOT NULL,
    CredentialId     VARBINARY(256) NOT NULL UNIQUE,
    PublicKey        VARBINARY(512) NOT NULL,          -- COSE key
    SignCount        BIGINT       NOT NULL DEFAULT 0,
    AaGuid           UNIQUEIDENTIFIER NULL,            -- nhan dien model authenticator
    AuthenticatorAttachment VARCHAR(16) NULL,          -- "platform" | "cross-platform"
    Transports       VARCHAR(64)  NULL,                -- "internal,hybrid,nfc,usb"
    IsBackupEligible BIT          NOT NULL DEFAULT 0,  -- BE flag
    IsBackedUp       BIT          NOT NULL DEFAULT 0,  -- BS flag (synced passkey)
    UserVerified     BIT          NOT NULL DEFAULT 0,
    Nickname         NVARCHAR(100) NULL,               -- user dat ten: "iPhone cua Tu"
    CreatedAt        DATETIME2    NOT NULL DEFAULT SYSUTCDATETIME(),
    LastUsedAt       DATETIME2    NULL
);
CREATE INDEX IX_WebAuthnCredential_UserId ON WebAuthnCredential(UserId);

10. Implementation trên .NET 10 với Fido2NetLib 5.x

Fido2NetLib là thư viện chuẩn de-facto của cộng đồng .NET, được maintain bởi Anders Abel và team. Bản 5.x đã hỗ trợ .NET 10, WebAuthn Level 3, và parser attestation cho mọi format (packed, tpm, android-key, android-safetynet, apple-appattest, fido-u2f, none).

// Program.cs  — Minimal API setup cho .NET 10
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddFido2(options =>
{
    options.ServerName         = "AnhTu Demo";
    options.ServerDomain       = builder.Configuration["WebAuthn:RpId"];   // "anhtu.dev"
    options.Origins            = new HashSet<string> { "https://anhtu.dev" };
    options.TimestampDriftTolerance = 300_000;                             // 5 phut
    options.MDSCacheDirPath    = Path.Combine(AppContext.BaseDirectory, "mds");
})
.AddCachedMetadataService(mds =>
{
    mds.AddFidoMetadataRepository();
});

builder.Services.AddScoped<ICredentialStore, EfCredentialStore>();
builder.Services.AddDistributedMemoryCache();   // luu challenge tam thoi

var app = builder.Build();

app.MapPost("/webauthn/register/options", async (
    HttpContext ctx, IFido2 fido2, ICredentialStore store) =>
{
    var user = await store.GetCurrentUserAsync(ctx);
    var existing = await store.GetCredentialsAsync(user.Id);

    var options = fido2.RequestNewCredential(new RequestNewCredentialParams
    {
        User = new Fido2User { Id = user.Id.ToBytes(), Name = user.Email, DisplayName = user.FullName },
        ExcludeCredentials = existing.Select(c => new PublicKeyCredentialDescriptor(c.CredentialId)).ToList(),
        AuthenticatorSelection = new AuthenticatorSelection
        {
            ResidentKey            = ResidentKeyRequirement.Required,
            UserVerification       = UserVerificationRequirement.Required,
            AuthenticatorAttachment = AuthenticatorAttachment.Platform
        },
        AttestationPreference = AttestationConveyancePreference.Direct
    });

    ctx.Session.SetString("fido2.register", JsonSerializer.Serialize(options));
    return Results.Ok(options);
});

app.MapPost("/webauthn/register/verify", async (
    HttpContext ctx, AuthenticatorAttestationRawResponse raw,
    IFido2 fido2, ICredentialStore store) =>
{
    var options = JsonSerializer.Deserialize<CredentialCreateOptions>(
        ctx.Session.GetString("fido2.register")!)!;

    var result = await fido2.MakeNewCredentialAsync(new MakeNewCredentialParams
    {
        AttestationResponse = raw,
        OriginalOptions     = options,
        IsCredentialIdUniqueToUser = async (args, _) =>
            !await store.CredentialIdExistsAsync(args.CredentialId)
    });

    await store.AddAsync(new WebAuthnCredential
    {
        UserId          = ctx.GetCurrentUserId(),
        CredentialId    = result.Result!.CredentialId,
        PublicKey       = result.Result.PublicKey,
        SignCount       = result.Result.SignCount,
        AaGuid          = result.Result.AaGuid,
        IsBackupEligible = result.Result.BackupEligible,
        IsBackedUp      = result.Result.BackupState,
        UserVerified    = true,
        Transports      = string.Join(',', result.Result.Transports ?? Array.Empty<string>())
    });

    return Results.Created();
});

app.Run();

Phần authentication tương tự với fido2.GetAssertionOptions(...) và fido2.MakeAssertionAsync(...). Điểm cần nhớ: khi dùng Conditional UI, danh sách allowCredentials nên trả về rỗng và cho phép authenticator tự chọn credential resident — đây là cách user không cần gõ username.

11. Implementation phía Vue 3.6 với SimpleWebAuthn browser

Phía frontend, @simplewebauthn/browser giúp bạn không phải tự xử lý base64url encode/decode (vốn là nguồn bug âm thầm phổ biến). Composable Vue dưới đây tận dụng script setup và defineModel của 3.6:

// composables/usePasskey.ts
import {
  startRegistration,
  startAuthentication,
  browserSupportsWebAuthn,
  browserSupportsWebAuthnAutofill
} from '@simplewebauthn/browser'
import { ref } from 'vue'

export function usePasskey() {
  const isSupported = ref(browserSupportsWebAuthn())
  const isLoading = ref(false)
  const error = ref<string | null>(null)

  async function register() {
    isLoading.value = true
    error.value = null
    try {
      const options = await $fetch('/api/webauthn/register/options', { method: 'POST' })
      const attResp = await startRegistration({ optionsJSON: options })
      await $fetch('/api/webauthn/register/verify', { method: 'POST', body: attResp })
    } catch (e: any) {
      error.value = e?.message ?? 'Tao passkey that bai'
    } finally {
      isLoading.value = false
    }
  }

  async function signInConditional(onSuccess: () => void) {
    if (!(await browserSupportsWebAuthnAutofill())) return
    const options = await $fetch('/api/webauthn/assert/options', { method: 'POST' })
    const assResp = await startAuthentication({
      optionsJSON: options,
      useBrowserAutofill: true
    })
    await $fetch('/api/webauthn/assert/verify', { method: 'POST', body: assResp })
    onSuccess()
  }

  return { isSupported, isLoading, error, register, signInConditional }
}

Ở template login, chỉ cần gắn attribute autocomplete="username webauthn" vào input email là browser tự gợi ý passkey. Gọi signInConditional trong onMounted để kích hoạt Conditional UI ngay khi trang load:

<script setup lang="ts">
import { onMounted } from 'vue'
import { usePasskey } from '@/composables/usePasskey'
const { signInConditional } = usePasskey()
const router = useRouter()
onMounted(() => signInConditional(() => router.push('/app')))
</script>

<template>
  <form @submit.prevent="loginPassword">
    <input v-model="email" autocomplete="username webauthn"
           placeholder="Email" />
    <input v-model="password" type="password"
           autocomplete="current-password" placeholder="Mat khau (tuy chon)" />
    <button type="submit">Dang nhap</button>
  </form>
</template>

12. Chiến lược migration — Từ password sang passkey

Ít sản phẩm đủ dũng cảm để "flip switch" đổi toàn bộ base user sang passkey cùng lúc. Phương án ổn định nhất là migration ba pha, kéo dài 9–15 tháng tuỳ quy mô.

flowchart LR
    subgraph Pha1["Pha 1: Dong hanh"]
        P1[Password + OTP
van la chinh] --> Offer[Banner moi tao passkey
sau khi login thanh cong]
    end
    subgraph Pha2["Pha 2: Uu tien passkey"]
        Offer --> Preferred[Passkey uu tien
Password ban ro trong advanced]
    end
    subgraph Pha3["Pha 3: Passwordless mac dinh"]
        Preferred --> Default[Chi passkey +
magic link recovery
Password bi ngung moi]
    end

• Pha 1 (3–6 tháng): mời user tạo passkey sau khi đăng nhập thành công, khi đổi password, khi kích hoạt 2FA. Metric thoát: 30% MAU có ít nhất một passkey.
• Pha 2 (3–6 tháng): Conditional UI bật mặc định, button "đăng nhập bằng password" bị đẩy xuống "phương án khác". Metric thoát: 60% MAU login lần gần nhất bằng passkey.
• Pha 3 (3 tháng): account mới bắt buộc có passkey. User cũ chưa có passkey được yêu cầu tạo sau 3 lần login. Password vẫn lưu nhưng dùng như recovery factor, kèm step-up (email + one-time code) mỗi lần dùng.

13. Observability — Metric và trace cần có

Một hệ passkey production tốt cần quan sát được mấy chỉ số sau, mỗi chỉ số đều có thể bảo bạn "hệ đang hỏng ở đâu":

Tích hợp OpenTelemetry cho cả request chain — ghi rõ AAGUID và transport trong span attribute, bạn sẽ nhanh chóng nhìn thấy "model authenticator X có rate lỗi 40%" để cô lập firmware issue. Fido2NetLib 5.x đã expose các Activity Source theo chuẩn, chỉ cần bật AddSource("Fido2NetLib").

14. Bốn anti-pattern hay gặp

1. Ép attestation "direct" cho mọi tài khoản: với consumer B2C, direct attestation gây phiền (popup xin permission, và một số passkey cloud không trả về cert). Chỉ nên direct cho nhóm tài khoản cần compliance. Mặc định để "none" hoặc "indirect".
2. Dùng username làm user.id: spec yêu cầu user.id là bytes đối nghịch với thông tin định danh (ví dụ UUID hoặc hash). Nếu bạn dùng email làm id, đổi email là phá luôn tất cả passkey đã đăng ký.
3. Bỏ excludeCredentials khi register: user đã có passkey cho tài khoản đó vẫn có thể tạo thêm trùng, dẫn đến schema có row "ma" hoặc UX confusing. Luôn truyền danh sách credential hiện tại vào options.
4. Giữ password như recovery: đặt passkey là phương thức chính nhưng password vẫn là cửa sau không cần step-up — attacker sẽ chỉ tấn công cửa sau. Hoặc bắt password vẫn phải qua step-up nặng, hoặc loại bỏ hẳn.

15. Checklist go-live

16. Lời kết — Khi nào nên làm và khi nào chưa nên

Passkey là một trong số rất ít công nghệ trong 20 năm qua vừa cải thiện cả bảo mật lẫn trải nghiệm cùng một lúc — thường thì hai thứ này đánh đổi nhau. Năm 2026, nền tảng đã đủ chín, thư viện đã đủ tốt, người dùng đã quen nhìn thấy Touch ID ở khắp nơi. Không còn nhiều lý do kỹ thuật để trì hoãn.

Tuy vậy, thời điểm triển khai vẫn cần cân nhắc. Nếu sản phẩm của bạn có nhiều kiosk chia sẻ thiết bị, nhiều tài khoản dùng chung trong doanh nghiệp nhỏ, hoặc user chủ yếu là người cao tuổi chưa quen sinh trắc — lộ trình cần thận trọng hơn, giữ password lâu hơn, hướng dẫn UI kỹ hơn. Ngược lại, với sản phẩm consumer tech-savvy (fintech, productivity SaaS, developer tool), bạn có thể đẩy nhanh pha 1–2 và thu hoạch ngay về cả bảo mật và conversion.

Dù chọn tốc độ nào, nguyên tắc bất biến vẫn là: đừng coi passkey là "một kênh thêm vào bên cạnh OTP". Nó là sự thay thế — và chỉ khi bạn thực sự loại bỏ các kênh phishable khỏi luồng chính, lợi ích bảo mật mới xuất hiện. Một hệ thống có passkey nhưng vẫn cho phép "gửi OTP về email" làm recovery cho mọi tài khoản, về mặt bảo mật, chính xác bằng hệ thống chỉ có email OTP.

17. Nguồn tham khảo

• W3C Web Authentication: An API for accessing Public Key Credentials — Level 3
• FIDO Alliance Specifications (CTAP 2.2, Metadata v3)
• FIDO Alliance — Passkeys Overview
• Fido2NetLib — Source code và docs
• SimpleWebAuthn — Browser và server guide
• webauthn.guide — Giải thích trực quan luồng đăng ký và đăng nhập
• Apple Developer — Passkeys
• Google Identity — Passkeys
• Microsoft Learn — Passwordless authentication options
• web.dev — Passkey Form Autofill (Conditional UI)
• FIDO Metadata Service v3
• RFC 9052 — CBOR Object Signing and Encryption (COSE)