Configure WebAuthn with Security Keys for MFA
For an introduction to WebAuthn and how Auth0 implements it for both Security Keys and Device Biometrics, check out FIDO Authentication with WebAuthn.
Availability varies by Auth0 plan and login method
Both the login implementation you use and your Auth0 plan or custom agreement affect whether this feature is available. To learn more, read New Universal Login vs. Classic Universal Login and Pricing.
If you need to set a custom domain, do so before rolling out WebAuthn in production environments. If you set or change a custom domain, previously enrolled users will not be able to authenticate.
You can use the Relying Party setting to specify the domain used to authenticate users.
Use the Dashboard
Enable WebAuthn with Security Keys by going to Dashboard > Security > Multi-factor Auth.
Configure how you want to handle User Verification. For security keys, the typical user verification prompts users to enter a PIN to complete the WebAuthn challenge.
Never: Users will never be prompted to enter a PIN. This is the default value, and it's usually good enough when using security keys for MFA. Users already entered their password, so already provided some verification.
If supported: Users will be prompted to enter a PIN if they already configured one in the key.
Required: Users will be asked to set a PIN if it's not already set, and they'll be asked to enter it each time. This is the option that offers the highest security. Some browsers don't implement this properly (for example, Brave on iOS) so the authentication will fail and Auth0 will ask users to use another browser.
Note that only FIDO-2 compliant security keys support user verification. FIDO-1 keys can be used for WebAuthn, but are not usable if you set User Verification to Required.
Configure Relying Party
WebAuthn makes phishing impossible by binding the credentials with the browser's origin. Users can't use WebAuthn for a site they did not register too.
Binding credentials to the origin means if you configure a custom domain or change it, users enrolled before the change will not be able to authenticate.
WebAuthn defines a Relying Party ID attribute, which lets you specify the domain used to authenticate users. You can set it to any registrable domain suffix of the browser origin. For example, if the custom domain is accounts.acme.com, you can configure the Relying Party ID to acme.com. This lets users authenticate to any acme.com domain with their WebAuthn credentials.
Auth0 lets you specify the Relying Party ID only if you have a custom domain configured. If the custom domain changes, you must update the Relying Party ID.
Device support
To use security keys, a browser needs to have JavaScript enabled and support WebAuthn. If those conditions are not met, Auth0 will not offer the option of enrolling or authenticating with security keys. Auth0 will challenge with another factor or with a recovery code (if they don't have another factor enrolled).
The latest versions of popular browsers and operating systems provide support for WebAuthn with Security Keys. For more details, read the the browser support section in webauthn.me.
Limitations
When using the MFA API you can list and remove WebAuthn enrollments, but you cannot enroll them.