FIDO2 Passwordless Authentication: How It Works in Keycloak

What is FIDO2 passwordless authentication?

FIDO2 authentication is an open standard for signing in with public-key cryptography instead of a password. Your device creates a key pair for each website, keeps the private key, and signs a login challenge after you unlock it with a biometric or PIN. Each key only works for the site that created it, so phishing pages cannot reuse it.

The name comes from the FIDO Alliance, where FIDO stands for Fast Identity Online, and FIDO2 is the second generation of its specifications. Passwords have been the default way to protect accounts for decades, but they fail in predictable ways: people reuse them across sites, they get leaked in breaches, and phishing pages collect them by the thousand. Classic multi-factor authentication helps, but a one-time code can be phished just as easily as a password, because the user types it into whatever page is in front of them. FIDO2 removes the shared secret altogether, which is why it has become the foundation for passkeys and for phishing-resistant MFA.

This post explains how FIDO2 works, how it compares with the other factors you might already use, and how to enable it in Keycloak 26.x. If you are ready to configure it step by step, our complete guide to Keycloak passkeys and WebAuthn walks through every screen.

The two parts of FIDO2: WebAuthn and CTAP

FIDO2 is made of two specifications that work together, and it helps to know which one does what when you read documentation or debug a login.

• WebAuthn (Web Authentication) is a W3C standard that defines a JavaScript API in the browser. A website (called the relying party, meaning the service that relies on the credential to identify you) calls this API to create a new credential or to ask for a signed login.
• CTAP (Client to Authenticator Protocol) is the FIDO Alliance protocol that the browser or operating system uses to talk to an authenticator, which is the thing that actually holds the private key. That might be a USB or NFC security key, or it might be a phone sitting next to your laptop.

Authenticators come in two broad kinds. A platform authenticator is built into the device you are using, such as Windows Hello, Touch ID on a Mac or the secure hardware in an Android phone. A roaming authenticator is separate hardware you can carry between devices, such as a YubiKey. Both are reached through the same WebAuthn API, so the website does not need to care which one the user picked.

How does FIDO2 work?

FIDO2 authentication happens in two phases. Registration happens once per site and device, and authentication happens every time the user signs in.

1. Registration. The website sends the browser a random challenge along with its relying party ID, which is normally its domain name. The authenticator asks the user to confirm, usually with a PIN or biometric (or a plain touch if the site did not ask for user verification), generates a new key pair that is unique to that site, and stores the private key. The browser returns the public key and a credential ID to the website, which saves them against the user’s account.
2. Authentication. On the next login, the website sends a fresh random challenge. The browser only lets a page ask for credentials scoped to its own domain, so the authenticator looks up the key for that relying party ID, asks the user to verify, and signs the challenge with the stored private key. The website checks the signature with the public key it saved during registration, and if it matches, the user is signed in.

Two details in this process do most of the security work. First, the private key never leaves the authenticator and is never sent over the network, so there is nothing for an attacker to intercept or for the website to leak. Second, the browser includes the real origin of the page in the data that gets signed, and every credential is scoped to the relying party ID it was created for. A credential created for example.com simply will not respond to a look-alike domain, which is what makes FIDO2 resistant to phishing rather than just harder to phish.

The fingerprint or face scan is checked locally by the authenticator. The website never receives the biometric itself, only a flag saying that user verification happened and the signed result.

FIDO2 vs passwords, OTP and SMS codes

Most teams adopt FIDO2 after they already have some form of MFA, so the useful comparison is against what you probably run today.

The last column matters as much as the security columns. A FIDO2 login is usually a single touch or glance, which is faster than finding and typing a six-digit code. That is why FIDO2 is often deployed to replace the password entirely, rather than as one more step on top of it.

The “what the server stores” column is the other big difference. A database breach of a FIDO2 deployment only exposes public keys, which cannot be used to sign in anywhere. A breach of an OTP deployment exposes the shared secrets, which an attacker can use to generate valid codes.

FIDO2, WebAuthn and passkeys: what is the difference?

These three terms are often used as if they mean the same thing, and the overlap is real, but each one names something slightly different.

• FIDO2 is the overall standard: WebAuthn plus CTAP.
• WebAuthn is the browser API that websites call. When Keycloak’s documentation talks about “WebAuthn”, it means the FIDO2 support built into Keycloak.
• A passkey is a FIDO2 credential that is discoverable, meaning the authenticator stores enough account information to offer it to the user without them typing a username first. Passkeys can be synced between a user’s devices by their platform (for example through an Apple, Google or password-manager account) or bound to a single device such as a hardware key.

In practice, every passkey is a FIDO2 credential, but not every FIDO2 credential is a passkey. A security key registered purely as a second factor after a password, without a discoverable credential, is FIDO2 but would not usually be called a passkey. Our post on why everyone is talking about passwordless authentication covers the wider shift toward passkeys.

Using FIDO2 for two-factor authentication or for passwordless login

You can use a FIDO2 credential in two different positions in a login flow, and Keycloak supports both in the same realm.

As a second factor, the user still enters a username and password, and the security key or device check replaces the one-time code. This is the easiest change to roll out, because it fits into the MFA step you already have, and it gives you phishing resistance for the second factor straight away.

As a first factor (passwordless), the FIDO2 credential replaces the password itself. With a discoverable credential the user can even skip typing their username, because the browser offers the saved passkey in the login form. This gives the biggest improvement in both security and convenience, but it needs a little more planning around account recovery, because the user no longer has a password to fall back on.

Many teams start with FIDO2 as a second factor for administrators and staff, then offer passwordless sign-in to everyone once they are comfortable with recovery and support processes. Skycloak’s passwordless and multi-factor authentication features cover both setups on managed Keycloak.

How to enable FIDO2 in Keycloak

Keycloak FIDO2 support works through WebAuthn, with Keycloak acting as the relying party, and the server administration guide documents both modes. The steps below apply to Keycloak 26.x in the current admin console.

FIDO2 as a second factor

1. In the admin console, open Authentication, go to the Required actions tab and make sure Webauthn Register is switched on. Turn on Default Action as well if you want every new user to register a security key.
2. Open the Policies tab, then WebAuthn Policy, and review the settings. User verification requirement controls whether the authenticator must check a PIN or biometric, and Authenticator Attachment lets you restrict registration to platform or cross-platform (roaming) authenticators.
3. Open the browser flow. Inside the Browser – Conditional 2FA sub-flow, change WebAuthn Authenticator from Disabled to Alternative, so users can choose it alongside OTP. To enforce security keys for everyone, change the Browser – Conditional 2FA sub-flow itself from Conditional to Required, set OTP Form to Disabled, and set WebAuthn Authenticator to Required. Users without a credential are then asked to register one at login.

Keycloak only asks for the second factor when the user has registered a credential of that type, because the 2FA sub-flow is conditional.

FIDO2 as a passwordless first factor (passkeys)

1. On the Required actions tab, make sure Webauthn Register Passwordless is switched on.
2. Review the WebAuthn Passwordless Policy on the Policies tab. Its defaults require user verification and a discoverable credential, which is what passkeys need, so the defaults are usually enough.
3. Turn on passkeys for the login forms. In current 26.x releases the Enable Passkeys switch is under Realm settings, Login tab, in Login screen customization. It is the same setting that appears in the WebAuthn Passwordless Policy, which is where the release notes for Keycloak 26.4, the release in which passkeys became fully supported, first pointed to it. Recent releases also show a Passkey Mediation option next to it, which defaults to offering passkeys through the browser’s autofill.

Once passkeys are enabled, the username field in the default login form offers saved passkeys through the browser’s autofill, and a Sign in with Passkey button opens the browser’s passkey dialog directly. The default browser flow also contains a Condition – credential step in its 2FA sub-flow, so a user who signed in with a passkey is not asked for a second factor again. Set that condition to Disabled if you want 2FA after a passkey login too.

Users register a credential either when the required action prompts them at login, or from the Account Console under Account security, Signing in. Applications can also trigger registration with the kc_action=webauthn-register or kc_action=webauthn-register-passwordless parameters, which Keycloak calls application-initiated actions.

For screenshots, the older loginless flow, and Windows Hello specifics (it needs RS256 added to the policy’s signature algorithms), see the complete Keycloak passkeys and WebAuthn guide. If you are adding passkeys to a single-page app, our React and Next.js passkeys integration covers the front-end side.

Benefits of FIDO2 for organizations

The advantages of FIDO2 follow directly from how the protocol works, so they are worth stating plainly.

• Phishing resistance. Because credentials are bound to the real domain and the browser signs the true origin, a fake login page cannot collect anything it could replay against the real site. This is the main reason security teams move from OTP to FIDO2.
• No shared secrets on the server. The server only stores public keys, so a database leak does not give an attacker anything they can log in with, and credential stuffing (trying passwords leaked from other sites) stops working against FIDO2-only accounts.
• Faster logins. A touch or a glance is quicker than typing a password and a code, which matters for staff who sign in many times a day and for customers deciding whether to finish signing up.
• Fewer password resets. Once users sign in without a password there is nothing for them to forget, so help desk tickets for resets and lockouts go down.
• Stronger evidence for compliance. Rules such as PSD2’s strong customer authentication in the EU ask for two independent factors. A FIDO2 credential with user verification combines possession of the device with a PIN or biometric in one step, which can help you meet that requirement. Confirm the details with your own compliance team, because how a regulator reads a given setup can vary.

Challenges to plan for before rolling out FIDO2

FIDO2 is mature, but a smooth rollout still needs some planning in a few areas.

Account recovery. If a user loses their only security key, they need a safe way back in. Ask users to register at least two authenticators, or rely on synced passkeys that survive the loss of one device, and decide in advance how your help desk verifies someone before resetting their credentials.

Device and browser support. All major browsers support WebAuthn, but some combinations behave differently, especially for syncing passkeys between ecosystems and for private browsing windows. Keycloak’s documentation points to passkeys.dev as the reference for which operations work on which platform. Keep a fallback method, such as a password plus OTP, for users whose devices cannot register a credential yet.

Hardware key storage. Hardware security keys can only hold a limited number of discoverable credentials. This rarely matters for second-factor use, but it is worth knowing if you plan to issue keys for passwordless login across many services.

User communication. People are used to passwords, so explain the change before it arrives. A short note that tells users what they will see, why it is safer, and what to do if they lose a device prevents most support questions.

Frequently asked questions

Is FIDO2 the same as a passkey?

Not exactly, because FIDO2 is the standard and a passkey is one particular kind of FIDO2 credential, the discoverable kind, which lets the user sign in without typing a username. All passkeys use FIDO2, but a security key used only as a second factor is FIDO2 without being a passkey.

Can FIDO2 be used for two-factor authentication?

Yes, FIDO2 works well as a second factor after a password, where it replaces the SMS or authenticator-app code. In Keycloak this is the WebAuthn Authenticator in the browser flow, and it gives you phishing-resistant MFA without asking users to give up their password yet.

Does Keycloak support FIDO2?

Yes, Keycloak FIDO2 support is built in through WebAuthn, as both a second factor and a passwordless first factor, with separate policies for each. Since Keycloak 26.4, passkeys are fully supported and integrated into the default login forms, so users can pick a saved passkey from the browser’s autofill.

What happens if a user loses their FIDO2 security key?

The user needs another registered authenticator or an account recovery process. That is why it is good practice to register two security keys, or to use synced passkeys that are backed up to the user’s platform account. In Keycloak, an administrator can delete the lost credential from the user’s Credentials tab and assign the Webauthn Register (or Webauthn Register Passwordless) required action, so the user registers a new one at their next login.

Is FIDO2 more secure than SMS or authenticator-app codes?

Yes, mainly because FIDO2 credentials are bound to the website’s domain, so a phishing page cannot capture and replay them the way it can relay a one-time code. FIDO2 also avoids storing shared secrets on the server, so a database breach does not expose anything an attacker can sign in with.

Getting started with FIDO2 on managed Keycloak

FIDO2 lets you replace passwords and one-time codes with a credential that cannot be phished, and Keycloak 26.x supports it both as a second factor and as full passwordless login with passkeys. A practical path is to enable WebAuthn as a second factor for your administrators first, then turn on passkeys for everyone once your recovery process is in place.

If you would rather not run Keycloak yourself, Skycloak provides managed Keycloak with these features available from the admin console. You can compare the cost of self-hosting Keycloak with a managed service, estimate your bill with our pricing calculator, or see the plans on the Skycloak pricing page.