Authentication · Passwordless
Sign in without a password to steal
We roll out passkeys on Keycloak using its WebAuthn passwordless support — device biometrics and security keys, a sensible fallback, and a migration path that brings existing password users along gradually.
- Passkeys via WebAuthn / FIDO2
- Touch ID, Windows Hello & Android
- Runs on upstream Keycloak 26.x
Standards & integrations
- WebAuthn
- FIDO2 / CTAP2
- Passkeys
- Touch ID & Face ID
- Windows Hello
- Android biometrics
- Hardware security keys
Overview
Passwords are the weakest step in most logins
Passkeys replace a shared secret with a key pair bound to the user's device, so there is nothing to phish, reuse or leak from a database. Keycloak supports this through its WebAuthn passwordless policy, but a good rollout also needs enrolment prompts, a fallback for devices that can't take part, and a recovery route for lost ones. We design all of it, and move your users over at a pace your support team can handle.
What we deliver
- Device and user readiness assessment
- WebAuthn passwordless policy tuned to your authenticators
- Authentication flows with passkey sign-in and fallback, as code
- Enrolment prompts and login theme updates
- Lost-device recovery runbook for support
- Phased rollout plan for retiring passwords
Capabilities
What Passwordless covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Passkeys on Keycloak
The WebAuthn passwordless policy with discoverable credentials lets users sign in with a passkey and no username or password at all.
Platform authenticators
Touch ID, Face ID, Windows Hello and Android screen lock act as authenticators, with user verification required so the device confirms who is holding it.
Cross-device and security keys
When a laptop holds no passkey, the browser's cross-device flow can use a nearby phone, and hardware security keys cover shared machines.
Fallback and recovery
Alternative flow steps keep a secondary method available for unsupported devices, and a documented recovery path re-enrols users who lose theirs.
Gradual rollout
Required actions and conditional flows invite users to register a passkey group by group, while password login stays available until you decide to retire it.
Magic links by extension
Email magic links aren't part of upstream Keycloak; where you want them, we add a custom authenticator SPI and keep it tested against each upgrade.
How it works
From first call to production
Assess devices and users
We look at the browsers, operating systems and shared-device scenarios your users have, and decide where passkeys, security keys and fallbacks fit.
Configure and pilot
Passwordless policy, flows and required actions are defined as code and piloted with an internal group, covering registration, sign-in, cross-device and recovery.
Expand and retire passwords
Enrolment opens to wider groups in stages, and password login is removed from each flow once its users no longer rely on it.
Use cases
Where teams put it to work
Consumer apps
Returning customers sign in with a fingerprint or face scan instead of resetting a password they forgot months ago.
Phishing-resistant workforce access
Staff authenticate with passkeys or security keys that are bound to your domain and can't be replayed on a look-alike site.
Shared and kiosk devices
Frontline workers use a personal security key on shared terminals, with no password to write down or pass around.
FAQ
Passwordless questions, answered
What's the difference between passkeys and WebAuthn in Keycloak?
Passkeys are discoverable WebAuthn credentials, often synced across a user's devices by their platform. Keycloak's WebAuthn passwordless policy registers and verifies them; the syncing itself is handled by Apple, Google or Microsoft, not by Keycloak.
Do users have to give up passwords straight away?
No. Passwords and passkeys can coexist in the same flow, and we move users over in stages before removing password login where it's no longer needed.
Can Keycloak send magic links by email?
Not natively. When it suits your audience we add magic-link sign-in through a custom authenticator SPI or a maintained extension, and treat it as a convenience option rather than a replacement for passkeys.
What if a user loses the device holding their passkey?
Synced passkeys usually survive a lost device. Otherwise the user falls back to a second registered authenticator or a verified recovery path, then registers a new passkey.
Ready to roll out Passwordless?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.