webauthn-rs, a WebAuthn relying party for Rust servers

The relying party side of a three-part protocol

WebAuthn splits into an authenticator, a client, and a server, and webauthn-rs implements only the third of those. The README is explicit that the library is the Relying Party component of the WebAuthn and FIDO2 workflow, the part that generates challenges, verifies authenticator validity, and handles the registration and authentication ceremonies. The authenticator side is a separate part of the workspace, with fido-hid-rs and webauthn-authenticator-rs listed as authenticator interactions and fido-key-manager as a separate crate.

That scoping is the reason this project is worth a look even if you already have a working WebAuthn story elsewhere. A Rust server that needs to enrol a user's token, associate it with an account, and later accept a cryptographic assertion from it has to implement exactly the ceremony logic that this crate provides, and getting those ceremonies subtly wrong is a security problem rather than a bug.

The library also states that it provides template and example JavaScript and wasm bindings to demonstrate the browser interactions that the ceremony requires, so the browser half of the flow is not left as an exercise for the reader.

Three crates stacked, and the advice to use only the top one

The documentation splits the project into major parts. The safe, use-case driven API lives in Webauthn-RS on docs.rs. The low level, protocol level interactions live in Webauthn-RS-Core-RS. The protocol bindings live in Webauthn-RS-proto. A separate crate, FIDO-MDS, parses the FIDO MDS, the authenticator transparency data.

The README does not leave the choice open-ended. It strongly recommends the safe API, and gives the reason in one line: webauthn has many sharp edges and ways to hold it wrong. That is an unusually direct warning from a library author about their own protocol area, and it is the kind of statement worth taking at face value, because the failure mode of a badly implemented ceremony is an authentication bypass rather than a visible error.

The practical reading for an integrator: treat webauthn-rs-proto and webauthn-rs-core as implementation detail, and only descend into them when you have a specific reason and understand what you are changing.

Running the compatibility tester demo locally

The project ships a demonstration site, and the README gives a hosted instance at webauthn.firstyear.id.au as well as instructions for running it yourself. The demo lives in the compat_tester directory of the workspace, and the commands are:

    cd compat_tester/webauthn-rs-demo
    cargo run

To see the additional configuration options the demo exposes:

    cargo run -- --help

This is the crate you would reach for when you need to check a specific device. The README lists the keys and hardware that have been tested in some depth: Yubico 5c, 5ci, FIPS and Bio, TouchID and FaceID on iPhone, iPad and MacBook Pro, Android, Windows Hello with TPM, and softtokens. If your key and browser combination does not work, and the README attributes that generally to missing crypto routines, the suggested path is to run a compatibility test and then open an issue.

That combination of a hosted tester, a local runner and an issue tracker is the honest shape of WebAuthn support work. The protocol has enough device-specific behaviour that a matrix of what works is part of the deliverable.

The demo also ships as a container image

The repository includes a Dockerfile, and it builds the compatibility tester demo rather than a general purpose service. The builder stage installs the Rust toolchain with zypper, copies the tree into /home/webauthn-rs, and builds the demo crate in release mode. The runtime stage is much thinner, and it links the local time zone to Australia/Brisbane so timestamps in the demo are consistent.

The parts of the container worth reading before you build it are the runtime shape:

EXPOSE 8080
WORKDIR /
COPY --from=builder /home/webauthn-rs/target/release/webauthn-rs-demo /bin/
COPY --from=builder /home/webauthn-rs/compat_tester/webauthn-rs-demo/pkg /pkg
ENV RUST_BACKTRACE 1
CMD ["/bin/webauthn-rs-demo"]

The demo binary runs as the container's main process, it listens on port 8080, and RUST_BACKTRACE is set so a panic gives you a stack trace rather than a bare exit. Note that the base image family is openSUSE Tumbleweed with the OpenSSL development package installed in the build stage, so the build depends on a rolling distribution rather than a pinned one.

Two entries in the known-broken list that matter in the field

The README keeps a section for hardware that is known not to work, and it is worth reading before you promise passkeys to a user base. Pixel 3a and Pixel 4 with Chrome do not send correct attestation certificates and ignore requested algorithms, and the entry says plainly that this is not resolved.

The second entry is the one with security weight. Windows Hello with older TPMs often uses RSA-SHA1 signatures over attestation, which the README says may allow credential compromise or falsification. A library that surfaces that as a known-broken pairing is telling you something about its own threat model, and it changes how you think about attestation verification: an attestation you cannot trust is worse than no attestation, because it looks like evidence.

Neither entry is a reason to avoid the library. They are reasons to know which devices your users have, and to read what the library does with an attestation statement you cannot verify.

Level 3 support without a compliance claim

The standards section states that the implementation follows the w3c standard for WebAuthn level 3 and above processing, and then immediately declines to claim standards compliance. The four reasons given are specific: the library enforces extra constraints that go beyond the security guarantees the standard offers, certain esoteric options are not supported, not all cryptographic primitive types are supported and only secure ones are, and a large number of advertised WebAuthn features do not function in the real world.

Three of those four are design choices rather than gaps. Refusing weak primitives and adding constraints are decisions that narrow the surface at the cost of compatibility, and the fourth reason is an observation about the ecosystem rather than about this code.

The project also states that it has passed a security audit performed by SUSE product security, and that other security reviews are welcome. That is a named third-party audit with a named organisation, which is more information than most libraries in this area publish.

A workspace with a dozen crates, pinned to a recent Rust

The Cargo.toml describes a workspace rather than a single crate. Alongside the four documented crates it contains fido-mds and fido-mds-tool for the transparency data, device-catalog for the catalogue of devices, attestation-ca for the attestation structure format, sshkey-attest, webauthn-rp-proxy, authenticator-cli, cable-tunnel-server with backend, common and frontend members, and tutorial servers built on axum and actix_web, plus a wasm tutorial member that is excluded from the workspace because it needs the unstable web_sys APIs.

The workspace pins rust-version 1.88 and uses the 2021 edition, and the workspace package version is 0.5.5 with the internal crates pinned to exact matching versions, which is a pattern that keeps a multi-crate tree consistent. The most recent published release listed for the repository is v0.5.2 from 2025-07-30, while the workspace itself sits at 0.5.5, so the published crate and the tree are not the same version and depend on how you consume it.

The licence is MPL-2.0, the file per-file copyleft licence. It is a reasonable choice for a library you intend to embed in a larger server: modifications to the covered files stay open, while your own code that merely calls the API is not pulled in. The project also states a policy of not supporting blockchain related use cases and not accepting issues from organisations whose primary business is blockchain, cryptocurrency, NFTs or so-called Web 3.0 technology.

Editorial conclusion

webauthn-rs is the right choice for a Rust web server that needs passkey enrolment and assertion verification, and its layered crates let you start at the safe API and drop to webauthn-rs-core only when you have a reason to. It is the wrong choice if your stack is not Rust, if you need a vendor-supported security component, or if your users are on older Windows Hello hardware with TPM attestation, which the README lists as broken. Before adopting it, check that your devices appear in the device catalog and the compatibility tester at webauthn.firstyear.id.au/compat_test, read the constraint that the library deliberately enforces beyond the standard, and note that the workspace version is 0.5.5 while the last published release was v0.5.2 on 2025-07-30, so pin your dependency deliberately.

Frequently asked questions

Official sources

1. Issues
2. kanidm/webauthn-rs on GitHub
3. License: MPL-2.0
4. README
5. Releases