webauthn-rs

webauthn-rs is a Rust library implementing the Relying Party side of the WebAuthn/FIDO2 standard, letting Rust web servers register and authenticate users with hardware security keys, platform authenticators like Touch ID and Windows Hello, and synced passkeys instead of passwords. The crate wraps a strict, use-case driven API (WebauthnBuilder, Webauthn) around the lower-level protocol handling in webauthn-rs-core, generating and verifying the challenges, attestation, and assertions the WebAuthn ceremony requires while keeping risky options behind explicit opt-in feature flags.

The project ships as a Cargo workspace of focused crates: webauthn-rs for the safe server API, webauthn-rs-core for protocol internals and cryptography, webauthn-rs-proto for wire types, and fido-mds/attestation-ca for authenticator metadata and trust, plus example Axum and Actix Web tutorial servers and a WASM browser demo. It has passed a third-party security audit performed by SUSE product security and is used in production by the Kanidm identity project.

What You Get

• A safe, high-level Webauthn API for passkey, security-key, and attested-passkey registration/authentication flows
• Low-level protocol and cryptographic verification via webauthn-rs-core, including attestation statement parsing
• Feature-gated escape hatches (danger-credential-internals, danger-allow-state-serialisation) for advanced integrations
• Example Axum and Actix Web tutorial servers plus a WASM browser demo showing the full registration/auth ceremony
• A FIDO Metadata Service (MDS) parser crate for verifying authenticator attestation against vendor-published metadata

Common Use Cases

• Replacing password login with passkey-based passwordless authentication on a Rust backend
• Adding hardware security key (FIDO2/U2F) support as a second factor alongside existing auth
• Building an identity provider or SSO service that needs standards-compliant WebAuthn ceremonies (e.g. Kanidm)
• Verifying authenticator attestation against FIDO metadata for compliance-sensitive deployments

Under The Hood

Architecture The workspace separates concerns across crates: webauthn-rs/src/lib.rs exposes the WebauthnBuilder/Webauthn types as the only entry point applications should touch, delegating challenge generation, response verification, and state-machine transitions to webauthn-rs-core/src/core.rs. interface.rs in both crates defines the serialisable session/credential types (PasskeyRegistration, PasskeyAuthentication, Passkey, SecurityKey) that keep internal Credential details opaque unless a danger-* feature is explicitly enabled, which is a deliberate boundary preventing accidental replay-attack-prone serialisation. Attestation parsing and trust chain validation live in a dedicated attestation.rs module, and webauthn-rs-proto isolates the wire-format types from the ceremony logic, so a change to the core abstraction (the Credential/attestation flow) would ripple through core.rs and attestation.rs but is largely insulated from the public API surface in webauthn-rs.

Tech Stack The crate is pure Rust on the 2021 edition (MSRV 1.88), using openssl/openssl-sys for cryptographic primitives, serde/serde_cbor_2/serde_json for CBOR and JSON (de)serialisation of WebAuthn messages, nom for binary parsing, x509-parser/der-parser for certificate handling in attestation verification, url and uuid for identifiers, and thiserror/tracing for error types and structured logging. Tutorial servers demonstrate integration with both Axum and Actix Web, and a WASM target (tutorial/wasm) shows the browser-side navigator.credentials calls.

Code Quality Tests are extensive and embedded as #[cfg(test)] modules directly in the implementation files (core.rs, crypto.rs, internals.rs, fake.rs), covering registration/authentication ceremonies and cryptographic edge cases rather than relying on a separate integration-test crate. CI (.github/workflows/ci.yml) runs cargo fmt --check plus a build-and-test matrix across stable and a pinned MSRV, and the project has undergone a third-party security audit by SUSE product security, which is unusually strong assurance for a crate in this space.

What Makes It Unique Unlike most WebAuthn bindings that expose a single flat API, webauthn-rs deliberately splits its API into distinct credential types (Passkey, SecurityKey, AttestedPasskey) mapped to different trust and discoverability guarantees, and gates internal credential access and state serialisation behind explicitly named “danger” feature flags so applications must opt in to riskier patterns rather than discovering them by accident. It also ships its own FIDO Metadata Service parser and attestation CA bundling, letting deployments verify authenticator provenance directly rather than depending on an external attestation service.