Understanding WebAuthn/FIDO2 in Authelia: the passkey and authenticator concepts, domain-bound credentials to fend off phishing, webauthn configuration with display_name and attestation, up to YubiKey enrollment and its comparison with TOTP.

In episode 9, TOTP added a second layer that protects leaked passwords. But TOTP still has one classic gap: a 6-digit code can be typed into a phishing site that clones the Authelia login page. The attacker doesn't steal the secret — they just trick the victim into entering the code in the wrong place.
WebAuthn closes that gap at the root. In this episode you'll understand the W3C standard that FIDO2 is based on: why its credentials are bound to the real domain, how Authelia implements it, how to configure WebAuthn behavior, up to the YubiKey enrollment process and the considerations for choosing WebAuthn or TOTP.
WebAuthn is a W3C standard that enables authentication using an authenticator — a device that stores a private cryptographic key. There are two types of authenticators:
At enrollment, the authenticator creates a key pair: a private key that never leaves the device, and a public key sent to Authelia. The private key can't be extracted — an attacker who steals Authelia's database only gets a useless public key without the physical device.
Its main advantage is origin binding. Every authentication includes a signature over the origin information (domain and scheme). A signature from the auth.example.com domain will never match a phishing domain like auth-example.net. This is where the fundamental difference lies: TOTP verifies "you know the same code", WebAuthn verifies "you hold a valid key for this domain".
Authelia presents WebAuthn as one of the second methods at the portal. The enrollment flow:
Thanks to SSO, one enrollment applies to all applications protected by Authelia — users don't need to register their YubiKey in every service. Authelia also supports enable_passkey_login, which allows logging in without a password at all using a passkey (passwordless), changing WebAuthn's role from just a second factor to a replacement for the first factor.
WebAuthn behavior is controlled through the webauthn section:
webauthn:
display_name: "Authelia"
attestation_conveyance_preference: "indirect"
timeout: "60 seconds"
selection_criteria:
discoverability: "preferred"
user_verification: "preferred"display_name: the name sent to the browser and displayed during the WebAuthn dialog.attestation_conveyance_preference: how much data about the authenticator is collected. none minimizes data, indirect obscures device identity, direct requests the attestation statement directly from the authenticator including the AAGUID (device model). The indirect default balances privacy and verification.timeout: the time limit for the WebAuthn interaction, written in a duration syntax like 60 seconds.selection_criteria: preferences for attachment, discoverability, and user verification at enrollment.Tip
For stricter settings in security-conscious organizations, enable attestation_conveyance_preference: "direct" and consider an AAGUID filter: a whitelist of device models allowed to be registered. This prevents users from using unauthorized authenticators.
The YubiKey is the most popular roaming authenticator. The enrollment process in Authelia:
Some YubiKeys support multiple slots, so you can register one key for several purposes. When an authenticator is lost or suspected compromised, remove it from the list via the portal or CLI:
authelia storage user webauthn list
authelia storage user webauthn delete john --identifier "yubikey-1"The same principle from TOTP applies: never rely on a single authenticator. A healthy strategy:
Both methods can coexist, but understanding their differences helps you decide which to make primary:
Important
The best pattern in production: make WebAuthn the primary second method for sensitive services because of its phishing resistance, but keep TOTP registered as a fallback. This combination maintains high security without locking users out when an authenticator is lost.
Key points of this episode:
display_name, attestation_conveyance_preference, and timeout.All the second methods so far run on your own devices: an authenticator app or a physical key. In episode 11, there's one more method that moves the decision to a third-party service — Duo Push. You'll integrate Authelia with Duo Security, install the API key, and understand when push notifications are better and when to fall back.