Biometric Authentication: Methods, Risks and Keycloak Setup

What is biometric authentication?

Biometric authentication verifies who someone is by measuring a physical or behavioral trait, such as a fingerprint, face, iris or voice, and comparing it with a template recorded at enrollment. On the web it usually happens on the user’s own device, which unlocks a cryptographic key, so the website receives a signed proof rather than the fingerprint or face itself.

That second sentence is the part most introductions leave out, and it changes how you should think about adding biometrics to an application. If you run Keycloak, you do not need a biometric scanner, a vendor SDK or a database of face templates to offer fingerprint or face login. You need WebAuthn, the browser standard behind passkeys, which Keycloak already supports. This guide covers the main biometric authentication methods, how biometrics fit into multi-factor authentication, the risks to plan for, and how to switch biometric login on in Keycloak 26.

Types of biometric authentication, with examples

Biometric methods fall into two groups. Physiological biometrics measure something about your body, and behavioral biometrics measure the way you do something. The OWASP Multifactor Authentication Cheat Sheet lists fingerprints, facial recognition and iris scans as the common physiological examples and treats behavioral signals such as keystroke patterns as a form of “something you are” as well.

Each method has its own trade-off between accuracy, cost and convenience. For most web and mobile applications the practical choice comes down to the fingerprint and face sensors that users already carry in their phones and laptops, because those are the sensors that browsers and operating systems expose through standard APIs.

How biometric authentication works

Every biometric identity authentication system follows the same two phases. During enrollment, a sensor captures the trait and turns it into a template, which is a mathematical summary of the features rather than a photo or a raw scan. During verification, the sensor captures the trait again and the system compares the new sample with the stored template. Because no two captures are identical, the comparison produces a similarity score, and the system accepts the user when the score passes a threshold.

That threshold is why biometric systems are described in terms of error rates rather than right or wrong answers. A false match (also called a false accept) happens when the system accepts the wrong person, and a false non-match (a false reject) happens when it rejects the right person. Raising the threshold makes false matches rarer but locks out more genuine users, so every product picks a balance between security and frustration.

Where the template lives matters even more for an application developer. There are two common designs:

1. On-device matching. The template stays in a secure area of the phone or laptop, the comparison happens on the device, and a successful match unlocks a private key that signs a login challenge. The server never receives biometric data. This is how passkeys with Touch ID, Face ID, Windows Hello and Android biometrics work.
2. Server-side matching. The application or a biometric vendor stores templates centrally and compares samples sent over the network. This is common for identity verification during onboarding (matching a selfie against a passport photo, for example), but it means you hold a database of biometric data that you must protect and justify.

For login, on-device matching is the better default in almost every case, because it gives you biometric convenience without you having to store or protect anyone’s fingerprint data.

Is biometric authentication multi-factor authentication?

Multi-factor authentication (MFA) means proving your identity with at least two different kinds of evidence: something you know (a password or PIN), something you have (a phone or security key) and something you are (a biometric). A biometric on its own is a single factor. It becomes part of real MFA when it is tied to a device the user possesses.

The US government’s digital identity guidelines say exactly this. NIST SP 800-63B-4 requires biometric comparison to be combined with an authenticated physical authenticator, so a fingerprint unlocking a key held on a specific device counts, while a fingerprint checked on its own does not. A passkey with user verification fits that description: possession of the device that holds the private key is one factor, and the fingerprint or face check that unlocks it is the second. The OWASP cheat sheet adds a detail that matters when you configure a server: for the passkey to count as MFA, the server must require user verification and check the user-verification flag in the response, because a simple touch only proves that someone was present.

Benefits of biometric authentication in identity management

The case for biometrics is mostly about removing the weakest parts of password-based login.

• Nothing to remember or retype. Users unlock with a touch or a glance, which is faster than a password plus a one-time code, and there is no password for them to reuse across sites.
• Phishing resistance, when paired with WebAuthn. A passkey is bound to the real domain, so a lookalike login page cannot collect anything it could replay. The biometric itself is not what stops phishing; the domain binding of the key it unlocks is.
• No secret on the server. With on-device matching the server stores only a public key, so a database leak gives an attacker nothing to log in with.
• Fewer password resets. Once people stop typing passwords, the help desk receives fewer reset and lockout tickets.

Risks and challenges of biometric authentication

Biometrics solve real problems, but they bring a few of their own that are worth planning for before rollout.

A biometric cannot be reset. If a password leaks, the user picks a new one, but nobody can pick a new fingerprint. OWASP lists this among the drawbacks of biometrics, and it is the strongest reason to keep matching on the user’s device instead of collecting templates on a server.

Biometric data is regulated. Under the GDPR, biometric data processed to uniquely identify a person is a special category of personal data, which you may only process under specific conditions such as explicit consent. On-device matching through WebAuthn largely avoids this, because the server never receives the biometric. If you do store templates centrally, involve your privacy and legal team early, because other jurisdictions have their own biometric privacy laws too.

Spoofing and sensor quality vary. A high-quality 3D face sensor is far harder to fool with a photo or a mask than a basic camera. On Android, for example, the platform separates Class 3 (“strong”) biometrics from Class 2 (“weak”) ones, and apps that unlock cryptographic keys should ask for the strong class.

False rejections and accessibility. Wet fingers, injuries, masks, lighting and some disabilities all cause genuine users to be rejected. Every biometric login needs a fallback, which on most devices is the device PIN, and your application should still offer another way in, such as a password with a one-time code.

Device loss and account recovery. If the only credential lives on a lost phone, the user is locked out. Ask users to register a second device, 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.

How to add biometric authentication to Keycloak

Keycloak does not ship its own fingerprint or face matcher, and it does not need one. It supports WebAuthn, the W3C standard that lets a browser ask the device’s authenticator (Touch ID, Face ID, Windows Hello, an Android fingerprint sensor or a hardware security key) to sign a login challenge. Keycloak acts as the relying party: it stores the public key, sends the challenge and verifies the signature, while the biometric check happens entirely on the user’s device. The key setting is User Verification Requirement, which tells the authenticator to verify the user with a PIN or biometric rather than just detect a touch.

You can use biometrics in two ways. The steps below apply to Keycloak 26.x in the current admin console.

Biometrics as a second factor after the password

1. Open Authentication, go to the Required actions tab and make sure Webauthn Register is switched on.
2. On the Policies tab, open WebAuthn Policy and set User Verification Requirement to required, so the authenticator must check a fingerprint, face or PIN. If you want only built-in device sensors and not roaming security keys, set Authenticator Attachment to platform (this is checked when the credential is registered).
3. Open the browser flow and, inside the Browser - Conditional 2FA sub-flow, set WebAuthn Authenticator to Alternative so users can choose it alongside a one-time code from an authenticator app (OTP). Because the sub-flow is conditional, users are only asked for it once they have registered a credential, and switching on Default Action for Webauthn Register prompts every user to register one at their next login. To require it for everyone, set the sub-flow itself to Required, OTP Form to Disabled and WebAuthn Authenticator to Required.

Biometrics as passwordless login with passkeys

1. On the Required actions tab, make sure Webauthn Register Passwordless is switched on.
2. Review the WebAuthn Passwordless Policy. Keycloak’s defaults already set User Verification Requirement to required and Discoverable Credential to required (called Require Discoverable Credential, set to Yes, before 26.7), which is what passkey login needs. A discoverable credential is one the authenticator can find for the website on its own, so the user does not have to type a username before the biometric prompt appears. If your users sign in with Windows Hello, add RS256 to Signature Algorithms, as the Keycloak documentation advises.
3. Enable passkeys for the realm with the Enable Passkeys switch. Since Keycloak 26.7 it lives under Realm settings, Login tab, in the Login screen customization section; in 26.4 to 26.6 it sits at the bottom of the WebAuthn Passwordless Policy tab. Passkeys need Keycloak 26.4 or later. Once it is on, the username field then offers saved passkeys through the browser’s autofill, and a Sign in with Passkey button opens the device’s biometric prompt directly.

When passkeys are on, the default browser flow skips the second factor for a user who signed in with a passkey, because the passkey with user verification already combined two factors. A Condition - credential step in the 2FA sub-flow does this, and you can disable it if your policy demands a separate second factor anyway.

Users register a credential when the required action prompts them at login, or later in the Account Console under Account security, Signing in. For screenshots of the registration and login screens, see our complete Keycloak passkeys and WebAuthn guide, and for the protocol background read how FIDO2 passwordless authentication works.

When you need a custom authenticator instead

A few biometric methods cannot go through WebAuthn, for example voice verification from a call-center vendor or a palm scanner on a factory floor that exposes its own API. If the vendor offers an OpenID Connect or SAML login, you can avoid writing code: add it as an identity provider in Keycloak (identity brokering, where Keycloak hands the login to another identity system and trusts its answer), and the vendor’s own page performs the biometric check. Only when the vendor exposes a plain API do you need to write a custom authenticator, a Java class that Keycloak loads as a plugin through its Service Provider Interface (SPI) and adds as a step in an authentication flow. The skeleton below shows the methods Keycloak’s Authenticator interface requires; the vendor call itself depends entirely on the vendor’s API.

// Sketch of a custom Keycloak authenticator that delegates the biometric
// check to an external service. Register it with an AuthenticatorFactory.
// Imports from org.keycloak.authentication and org.keycloak.models omitted.
public class BiometricAuthenticator implements Authenticator {

    @Override
    public void authenticate(AuthenticationFlowContext context) {
        // Render a page that starts the vendor's biometric capture.
        context.challenge(context.form().createForm("biometric-capture.ftl"));
    }

    @Override
    public void action(AuthenticationFlowContext context) {
        // Called when the form posts back: ask the vendor to confirm the match.
        boolean verified = false; // replace with the vendor API call
        if (verified) {
            context.success();
        } else {
            // Re-show the capture page with an error and count the failed attempt.
            context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
                    context.form().setError("biometricFailed").createForm("biometric-capture.ftl"));
        }
    }

    @Override
    public boolean requiresUser() {
        return true; // the user must be identified before the biometric step
    }

    @Override
    public boolean configuredFor(KeycloakSession session, RealmModel realm, UserModel user) {
        return true; // return false if this user has not enrolled with the vendor
    }

    @Override
    public void setRequiredActions(KeycloakSession session, RealmModel realm, UserModel user) {
    }

    @Override
    public void close() {
    }
}

Building, packaging and deploying a provider like this is covered step by step in our Keycloak custom SPI development guide, and custom authentication flows in Keycloak explains where the new step goes in the flow. Keep in mind that a server-side biometric service brings back the template storage and privacy questions described above, so use this route only when WebAuthn genuinely cannot cover the method you need.

Where biometric authentication is heading

Most of the growth in biometric login is happening through passkeys rather than standalone biometric systems. Apple, Google and Microsoft all let users unlock passkeys with the fingerprint or face sensor already in their devices, and current browsers support WebAuthn (the passkeys.dev device support table tracks which platform supports what), so an application can offer biometric sign-in without shipping any biometric code.

Behavioral biometrics are moving the other way, into the background, where they feed risk scores that decide whether to ask for a step-up challenge rather than replacing the login itself. For a Keycloak deployment, that means the practical work is enabling passkeys with user verification, keeping a fallback for users without a capable device, and using step-up authentication for sensitive actions.

Frequently asked questions

What are examples of biometric authentication methods?

The common examples are fingerprint recognition, facial recognition, iris or retina scans and voice recognition, which all measure a physical trait. Behavioral biometrics, such as typing rhythm or the way someone moves a mouse, are a second group that measures how a person does something. In web and mobile apps, fingerprint and face are by far the most used, because the sensors are already built into phones and laptops.

Does Keycloak support biometric authentication?

Yes, through WebAuthn and passkeys. Keycloak acts as the WebAuthn relying party, and the user’s device performs the fingerprint or face check before signing the login challenge, so Keycloak never handles biometric data. Set User Verification Requirement to required in the WebAuthn policy to make sure a biometric or PIN check actually happens.

Is biometric authentication more secure than a password?

When it unlocks a passkey on the user’s device, yes, because the credential is bound to the real website and the server holds no reusable secret. A biometric checked on its own, without a device or key behind it, is weaker than it sounds, and NIST does not accept it as an authenticator by itself. The security comes from the combination of the device-bound key and the biometric that unlocks it.

What happens to biometric data in passkey login?

It stays on the user’s device. The phone or laptop compares the fingerprint or face with its locally stored template and, if they match, uses a private key to sign the login challenge. The website, including Keycloak, receives the signed challenge and the authenticator data, which includes a flag saying the user was verified, but never the fingerprint, face or template.

Is biometric authentication MFA?

On its own, a biometric is one factor (“something you are”). A passkey unlocked with a fingerprint or face counts as multi-factor authentication because it also proves possession of the device that holds the private key, provided the server requires and checks user verification.

Getting started with biometric login on managed Keycloak

If you want fingerprint and face login for your users without collecting any biometric data yourself, the path is to enable WebAuthn passkeys with user verification in Keycloak, keep a password and one-time-code fallback for devices that cannot register a passkey yet, and ask users to register a second device for recovery. Skycloak runs managed Keycloak with passwordless login and multi-factor authentication included on every plan, so you can turn these policies on from the admin console without operating the servers. You can book a demo to compare plans, or read about the cost of self-hosting Keycloak if you are weighing running it yourself.