A battle tested library for FIDO2, WebAuthn, and passkeys using .NET.
Bringing passkeys to asp.net and .NET Core.
Passkeys, FIDO2 & WebAuthn for .NET
Enabling simple, secure authentication and mfa using FIDO2 / WebAuthn
A battle tested library for FIDO2, WebAuthn, and passkeys using .NET.
Bringing passkeys to asp.net and .NET Core.
The fastest way to see what this library does is the Playground — every WebAuthn Level 3 option this Relying Party can set, the exact request it sends, the decoded response, and a Credentials tab showing exactly what a real passkey management UI should (grouped by where the passkey lives, per passkeycentral.org's guidance). The scenario pages below are narrower, scripted walkthroughs of specific flows.
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.
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.
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.
prf extension
(§10.1.4), and the §5.1.10 signal method payload types
(UnknownCredentialOptions, AllAcceptedCredentialsOptions,
CurrentUserDetailsOptions)
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
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.
MetadataStatement, status reports); rendering it as icons and
a tooltip is this demo's own UI
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 following section explains some of the concepts mentioned in the scenarios below and in the Playground.
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 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).
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.
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.
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.
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.