This topic aims to document the Discourse project goals around FIDO2 / Webauthn authentication.
Adding Webauthn support to Discourse will increase the security of user accounts, enabling easily acessible password-less accounts using their devices secure features, like a smartphone fingerprint reader.
- Webauthn as a second factor authenticator (act like a Google Authenticator alternative)
- Webauthn as a first factor authenticator (act like a social login alternative)
- Webauthn as a multi factor authenticator (username-less login)
This will allow a Discourse user, who already has an active account to use Webauthn as a 2FA, where today we only support TOTP.
Any Webauthn method can work here, be it device biometrics (fingerprint header in Android, Windows Hello laptop), a device secure chip (TPM, secure enclave) or a hardware key (like a Yubikey).
This would be availiable for every user who browses with:
- Microsoft Edge on Windows, using Windows Hello (with facial recognition, fingerprint reader, or PIN)
- Chrome on macOS, using Touch ID
- Android Phone
- Laptop/Desktop/Phone + Physical Key (Yubikey, Google Titan)
Allows a user to sign in to their Discourse account using the Webauthn authentication as an alternative to a password. If a first-factor authenticator is set up, the user will be prompted to use the authenticator in lieu of a password.
The same authentication methods for second-factor authentication will work for first-factor authentication: biometrics, secure chip, or hardware key.
No password field
Will expose an alternative login method that only prompts for Webauthn input. The registered security key will additionally pass user ID information to the Discourse server.
This authentication method currently requires a modern authentication key (eg a Yubikey 5) plus Google Chrome 76+, since it relies in a feature called “Residential Keys”. Since this stores data on the authenticator there can be limits, for example Yubikey 5C can only store up to 25 of those.
Those flows are an evolution from the one for password-less logins, not a separate login flow. This allows for a iterative implementation.
No password field, adds extra checkbox for Residential keys usage
If the username is left blank we will try to fetch a
user_id from the autheticator