Passkeys, FIDO2 & WebAuthn for .NET

Enabling simple, secure authentication and mfa using FIDO2 / WebAuthn

FIDO2 .NET Library (WebAuthn / Passkeys)

A battle tested library for FIDO2, WebAuthn, and passkeys using .NET.

Bringing passkeys to asp.net and .NET Core.

Available on GitHub and Nuget.

Purpose

Enable passkey sign-in for all .NET apps (asp, core, native).

To provide a developer friendly and well tested .NET FIDO2 Server / WebAuthn relying party library for the easy validation of registration (attestation) and authentication (assertion) of FIDO2 / WebAuthn credentials — passkeys — in order to increase the adoption of the technology, ultimately defeating phishing attacks.

Consider becoming a backer.

What is a passkey?

The passwordless web is here

A passkey is a WebAuthn credential, branded for end users: FIDO Alliance's umbrella term for the public/private key pairs this standard creates, whether they sync across a person's devices via a credential manager (iCloud Keychain, Google Password Manager, 1Password, etc.) or live on a single hardware security key. Either way, authentication happens without a shared secret ever crossing the network, which is what makes phishing against a passkey fundamentally different from phishing a password: there is no password to trick someone into typing into the wrong site.

WebAuthn/FIDO2 is the open standard behind passkeys, supported by every major browser and platform. It is not limited to web applications — support extends to native apps and Active Directory as well.

Read more

  • FIDO Alliance — the standards body behind FIDO2/WebAuthn and passkeys
  • passkeycentral.org — FIDO Alliance's passkey UX/design guidance
  • Yubico — a security key manufacturer, with good general WebAuthn background
  • WebAuthn.guide — a developer-focused introduction, from Duo Security
  • WebAuthn.io — a minimal demo/reference implementation
  • Awesome WebAuthn — a curated list of WebAuthn/passkey tools, libraries, and resources

Features

What the Fido2 NuGet package itself provides. Things this demo site does that aren't part of the library's own API are listed separately, below.

  • Attestation API & verification (Register and verify credentials/authenticators)
  • Assertion API & verification (Authenticate users)
  • WebAuthn Level 3 server-side support: hints (§5.8.8), attestation statement format preference (§5.4), conditional mediation (§5.1.3), the prf extension (§10.1.4), and the §5.1.10 signal method payload types (UnknownCredentialOptions, AllAcceptedCredentialsOptions, CurrentUserDetailsOptions)
  • 100% pass rate in FIDO Alliance conformance testing
  • Security keys aka roaming authenticators, like YubiKey and Feitian BioPass FIDO2
  • Platform authenticators and synced passkeys, like Windows Hello, Android, and every major credential manager
  • Backwards compatibility with FIDO U2F authenticators
  • All currently referenced cryptographic algorithms for FIDO2 Server, including the post-quantum ML-DSA family (RFC 9964)
  • All current attestation formats: "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple", "apple-appattest", and "none"
  • FIDO Metadata Service (MDS) v3.1.1 attestation & revocation validation
  • WebAuthn extensions
  • Fido2.BlazorWebAssembly: a separate package with client-side WebAuthn helpers for Blazor WASM
  • Fido2.Ctap2: a separate CTAP2 protocol implementation for talking directly to authenticators (making/getting credentials, credential management, the hmac-secret extension) — distinct from the Relying Party verification library above
  • Intellisense documentation

Also in this demo

These are things this Demo project does, on top of the library, or that come from the browser directly — not part of the Fido2 package's own API surface. Look at the Demo project's source if you're building your own.

  • The interactive Playground: request/response preview, a binary decoder, and a Credentials tab
  • Authenticator icons and a certification hover tooltip (status, certification record link, last status change, multi-device credential support, attestation types, key/matcher protection, protocol family/version) shown in the Playground — the library returns all of this MDS data (MetadataStatement, status reports); rendering it as icons and a tooltip is this demo's own UI
  • Grouping the Credentials tab into "Passkeys on your devices" / "Passkeys on security keys", with the guidance's recommended two-button empty state ("Create a passkey" / "Use a security key"), per passkeycentral.org's management-UI guidance — again, this demo's presentation of data the library already returns
  • §5.1.7 getClientCapabilities() and the actual §5.1.10 PublicKeyCredential.signalX() calls: both are browser APIs the demo's JavaScript calls directly. The .NET library's part is producing the signal payload (see the Features list above); it never talks to the browser's credential store itself
  • The scenario pages (Passkey Sign-In, Passkey With a Username) — example code, not something the library provides for you

Concepts

The following section explains some of the concepts mentioned in the scenarios below and in the Playground.

Passkey

The end-user-facing name for a WebAuthn credential. Per passkeycentral.org's guidance, a passkey lives either "on your devices" (synced to a credential manager, indicated by the WebAuthn Backup Eligible flag) or "on a security key" (device-bound hardware). The Playground's Credentials tab groups a signed-in user's passkeys the same way.

Fido2 vs WebAuthn?

Fido2 is the umbrella term and branding of two W3C/FIDO standards: WebAuthn and CTAP2. WebAuthn is the JS API that lets the browser talk to the operating system to generate assertions, and CTAP2 is the protocol that lets the operating system talk to external authenticators (security keys, etc).

Relying Party (RP)

The Relying Party - often called RP - is the server that the browser communicates with. If you are a developer reading this, the Relying Party is probably your webserver. It's the server that runs the fido2-net-lib library.

User Verification

A FIDO2 server (a.k.a the Relying Party, RP) can ask the authenticator to verify the user. This can be done either via PIN code, biometrics or other factors that securely verifies that it's the expected human in front of the device, not just any human.

Resident Credentials (RK) / Discoverable Credentials

A resident (discoverable) credential is one the authenticator can find on its own, given just the RP ID, without the Relying Party first supplying a list of candidate credential IDs. This is what makes a truly usernameless passkey sign-in possible: the authenticator (or the user's credential manager) locates all matching discoverable credentials, and the user picks one.

Backup Eligible / Backup State

Two flags a WebAuthn credential carries: whether it is eligible to be backed up/synced (a property of the authenticator, fixed at creation), and whether it is currently backed up. Together they're how a Relying Party can tell a synced passkey from a device-bound one, without asking the user — see the Credentials tab in the Playground for this in action.