Most applications eventually face login problems that have little to do with their core purpose.
Users forget passwords, reuse credentials, and struggle with account recovery. Meanwhile, developers must consider credential security, brute-force protection, and session management.
This is the reason why I started looking into passwordless authentication and how passkeys can potentially alter the login experience.
The idea is simple: users should be able to prove their identity without typing a conventional password every time they sign in.
Passkeys use public-key cryptography through standards such as WebAuthn. Users authenticate with a compatible device or security key, while the identity provider verifies the authentication and completes the login flow.
I was curious to find out what implications it has for developers: how the login procedure would change, what configuration the developers have to do, and which responsibilities remain with the app.
To answer these questions, I will explore the technology of passkey authentication and review Skycloak's managed Keycloak solution.
TL;DR
Passwordless authentication enables users to log in to their accounts without typing in a traditional password. With passkeys, the browser and the user's authenticator handle a cryptographic challenge, and the identity provider verifies the result.
Here are the important points for developers:
- The traditional password step is replaced with passkeys. When users authenticate using the passkey, they must use a suitable device or security key.
- WebAuthn enables public-key authentication. The authenticator uses a private key to respond to a challenge, and the identity provider verifies the response using the registered public key.
- Identity providers manage authentication. Keycloak supports passkeys, while Skycloak offers a managed Keycloak solution with a passkey setup provided.
- As usual, recovery must be taken care of. One must not forget that the users could end up losing their devices or switching browsers and want to register a passkey.
- Passwordless doesn't automatically mean MFA. Whether additional authentication factors are required depends on the configured authentication policy. A passkey can also satisfy multiple authentication-factor requirements in supported flows.
The main benefit is a simpler sign-in experience with strong phishing resistance when passkeys are correctly implemented. The trade-off is that developers still need to manage registration, recovery, device compatibility, and session security carefully.
Passwords Were Only the Beginning of the Problem
A login form looks simple from the outside. A user enters their credentials, the server verifies them, and the application starts a session. The complexity appears when something goes wrong.
Users forget passwords, attackers try leaked credentials, and account recovery can become a security weakness if it's poorly designed.
Developers must also protect stored passwords, limit repeated login attempts, and make sure reset links can't be abused.
For a growing application, these responsibilities add ongoing security work that competes with other product priorities.
This is where passwordless authentication becomes useful. Passkeys remove the need to remember and type a reusable password, reducing exposure to common password-related attacks.
They don't eliminate every authentication risk, though. Account recovery, session security, authorization, and fallback methods still need careful design. The goal is to simplify sign-in without compromising the security of the application.
How Passwordless Authentication Works
Passwordless authentication describes a login experience that doesn't require the user to enter a conventional password. There are several ways to achieve this, but passkeys are a useful starting point because they combine a straightforward user experience with public-key cryptography.
Passkeys: Prove Your Identity Without Typing a Password
When a user registers a passkey, their authenticator creates a public/private key pair. The private key is protected by the authenticator or passkey provider, while the identity provider stores the corresponding public-key credential.
During sign-in, the identity provider sends a challenge. The authenticator responds using the private key, and the identity provider verifies the response. If authentication succeeds, the user can continue into the application.
The browser handles this interaction through WebAuthn, a web standard for public-key authentication.
Depending on the device, users may confirm their identity with Face ID, Touch ID, Windows Hello, a device PIN, or a compatible security key. Their biometric data isn't sent to the application as part of the WebAuthn exchange.
┌──────────────────────────────┐
│ Sign in / Register │
│ │
│ Enter username or email │
│ Choose Register │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Register │
│ │
│ Username: hadil │
│ Email: hadil@example.com │
│ │
│ [ Register ] │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Choose Setup Method │
│ │
│ [ Setup Password ] │
│ OR │
│ [ Setup Passkey ] │
└──────────────┬───────────────┘
│
┌────────────────┴────────────────┐
│ │
▼ ▼
┌────────────────────────┐ ┌────────────────────────┐
│ Setup Password │ │ Setup Passkey │
└────────────┬───────────┘ └────────────┬───────────┘
│ │
▼ ▼
┌────────────────────────┐ ┌────────────────────────┐
│ Enter a new password │ │ Register a passkey │
│ Confirm the password │ │ with your device │
│ │ │ │
│ [ Register ] │ │ [ Continue ] │
└────────────┬───────────┘ └────────────┬───────────┘
│ │
│ ▼
│ ┌────────────────────────┐
│ │ Choose authenticator │
│ │ │
│ │ • Windows Hello │
│ │ • Touch ID / Face ID │
│ │ • Security key │
│ └────────────┬───────────┘
│ │
│ ▼
│ ┌────────────────────────┐
│ │ Confirm registration │
│ │ with device PIN, │
│ │ fingerprint or face │
│ └────────────┬───────────┘
│ │
└────────────────┬────────────────┘
│
▼
┌──────────────────────────────┐
│ Registration Complete │
│ │
│ User can sign in using the │
│ configured authentication │
│ method. │
└──────────────────────────────┘
This is a conceptual registration flow. The available authentication methods and registration steps depend on the application's identity provider and configured authentication flow.
For developers, passkeys still require configuration: users need a way to register credentials, the identity provider must accept them, and the application must establish a secure session after authentication.
Magic Links: A Different Way to Skip Passwords
Magic links offer another passwordless approach. The user enters an email address, receives a login link, and follows it to authenticate. The link typically contains a time-limited or one-time token that must be validated securely.
This can make onboarding straightforward because users don't have to create or remember a password. However, the experience depends on email delivery and on the security of the user's email account. Developers must also protect against token reuse, link leakage, and unsafe redirect handling.
Where Does Keycloak Fit Into the Flow?
Keycloak can manage authentication, user credentials, and the login flows that applications use through standard identity protocols. With passwordless authentication configured, it can verify a registered passkey and complete the authentication flow for the application.
┌─────────────────────────────┐
│ User │
│ │
│ Clicks "Sign in" │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Web Application │
│ │
│ React / Next.js / other │
│ application │
└──────────────┬──────────────┘
│
│ Redirects for login
▼
┌─────────────────────────────┐
│ Keycloak │
│ │
│ Identity and authentication│
│ Handles the configured │
│ login flow │
└──────────────┬──────────────┘
│
┌───────────┴───────────┐
│ │
▼ ▼
┌───────────────────┐ ┌───────────────────┐
│ Password │ │ Passkey │
│ authentication │ │ authentication │
│ │ │ │
│ Enter credentials │ │ Use device │
│ │ │ authenticator │
└─────────┬─────────┘ └─────────┬─────────┘
│ │
└───────────┬───────────┘
│
▼
┌───────────────────────────────┐
│ Keycloak Verifies Login │
│ │
│ Applies configured policies │
│ and completes authentication │
└───────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ OIDC Response │
│ │
│ Application receives the │
│ authorization code and │
│ completes the OIDC flow │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Web Application │
│ │
│ Establishes its session │
│ and checks authorization │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Protected Resource │
│ │
│ Access granted │
└─────────────────────────────┘
Developers can use an identity provider to manage the authentication process without having to build every part of credential registration and verification themselves. The application still needs to integrate correctly with the identity provider and handle its own authenticated sessions and authorization.
Passkeys vs. Passwords vs. MFA: What Changes?
These terms often appear together in authentication discussions, but they describe different things. Understanding the distinction helps you choose the right login flow for your application.
| Approach | What the user does | What it provides |
|---|---|---|
| Password-based login | Enters a username and password | Authentication using a memorized secret |
| Passwordless passkey login | Uses a registered passkey, often with a device unlock or security key | Authentication using public-key cryptography without entering a password |
| Multi-factor authentication (MFA) | Completes multiple authentication factors according to the configured policy | An additional layer of account protection |
A passkey can replace a password as the primary authentication method, while MFA requires multiple authentication factors according to the configured policy. The two can also work together: passkeys can support passwordless login or be incorporated into a multi-factor flow.
Passkeys offer strong phishing resistance because WebAuthn credentials are associated with the website's identity. A credential registered for one website can't simply be reused on an unrelated fake domain.
For developers, the right approach depends on the application's security requirements, its users' devices, and the available account recovery options.
Where Skycloak Comes In
Skycloak provides managed Keycloak, allowing developers to use Keycloak's identity and authentication capabilities without managing the underlying identity infrastructure themselves.
It includes a passkey configuration recipe for enabling passwordless registration and creating a dedicated browser-passkey authentication flow. The documented setup also describes a password-based fallback for users who haven't registered a passkey.
This configuration provides a starting point for exploring passkey authentication with Keycloak.
Using Skycloak for Passwordless Authentication With Passkeys
Passkeys change how users authenticate, but an application still needs an identity provider to manage registration, verify authentication, and handle the login flow. Skycloak provides managed Keycloak and a preconfigured Passkeys recipe that helps developers set up this flow without building a custom WebAuthn authenticator.
What the Skycloak Passkeys Recipe Configures
Skycloak's Passkeys recipe applies a passkey configuration to a selected Keycloak realm. It handles three main parts of the setup:
-
Passkey registration: Enables the
webauthn-register-passwordlessrequired action so users can register a passkey. -
A dedicated authentication flow: Creates a
browser-passkeyflow that identifies the user first and then prompts them to authenticate with a passkey. - Fallback authentication: Keeps password authentication and conditional OTP available for users who haven't registered a passkey, according to the configured flow.
The recipe leaves the existing browser flow untouched. It also provides an option to require passkey registration for existing users, so developers can choose when to enforce the change across a realm.
Prepare Your Development Environment
Start with a dedicated realm for your test application. Keeping the setup separate makes it easier to configure the authentication flow and test registration and sign-in without affecting other applications or users.
You'll need the following:
- Identity provider: A Skycloak-managed Keycloak environment with a development realm.
- Application: A small React or Next.js application with an OpenID Connect (OIDC) integration.
- Browser and authenticator: A WebAuthn-compatible browser and a supported authenticator, such as Windows Hello, Touch ID, or a security key.
- Test account: A dedicated user account for trying passkey registration and sign-in.
Connect the Application Through OIDC
The application needs an OIDC client in Keycloak so it can redirect users to the identity provider for authentication and receive the appropriate authentication response.
Configure the client's redirect URIs and other settings to match your application. Skycloak's first application setup guide provides guidance for creating the client.
Your application will also need the relevant issuer URL and client ID for its OIDC integration. Keep client secrets out of browser-side code, and use HTTPS in production.
Configure and Test Passkey Authentication
With the realm and OIDC client in place, follow Skycloak's Passkey configuration guide to apply the recipe and understand the resulting authentication flow.
Work through these steps:
1. Apply the Passkeys recipe.
Select your development realm and follow the documented instructions to enable passkey registration and create the browser-passkey flow.
2. Connect your application.
Configure the application's OIDC integration with the correct issuer URL, client ID, and redirect URI. The application should use the identity provider's authentication flow and handle the OIDC response according to its integration.
3. Register a passkey.
Sign in with your test account and follow the configured registration flow. The exact screens depend on the realm's configuration and the user's authentication state.
4. Test the sign-in flow.
Try signing in with the registered passkey using a compatible browser and authenticator. Also check the configured fallback for users who haven't registered a passkey.
5. Check recovery and failure scenarios.
Test what happens when a user cancels the browser prompt, has no registered passkey, or loses access to their authenticator. Confirm that the available fallback and recovery options work as intended.
What Developers Still Need to Handle
The recipe configures the identity-provider side of passkey authentication, but it doesn't remove the application's integration responsibilities. Developers still need to handle OIDC correctly, establish and protect application sessions, enforce authorization, and configure redirect URIs securely.
Before using the flow in production, test it across the browsers and devices your users rely on, and decide whether passkey registration should remain optional or become a requirement for the realm.
Edge Cases to Test Before Shipping
A passkey login that works once isn't enough for production. Developers need to consider recovery, device compatibility, and authentication failures before making passwordless authentication the default.
Account recovery is a priority. Users may lose a device or lose access to their authenticator. Provide a secure recovery process that helps legitimate users regain access without creating an easy route for attackers.
Test different browsers, operating systems, and authenticators relevant to your audience. Also check what happens when users cancel the passkey prompt, haven't registered a passkey, or try to access a protected page without an authenticated session.
Finally, remember that passkeys don't replace authorization checks, secure session handling, or session expiration policies. Authentication verifies a user's identity; the application still determines what they can access.
Before shipping, use this checklist:
- [ ] New users can register a passkey successfully.
- [ ] Returning users can sign in with a registered passkey.
- [ ] Users have a documented, secure account recovery process.
- [ ] Unsupported or cancelled authentication attempts are handled gracefully.
- [ ] Unauthenticated users cannot access protected pages.
- [ ] Redirect URLs, sessions, and identity-provider settings are configured securely.
- [ ] Relevant browser and device combinations have been tested.
Frequently Asked Questions
What is passwordless authentication?
→ Passwordless authentication allows users to sign in without entering a conventional password. It can use passkeys, security keys, magic links, or other password-free methods. Passkeys use public-key cryptography and can provide phishing-resistant authentication when correctly implemented.
How do passkeys work without a password?
→ A passkey uses a public/private key pair associated with the relying party. During authentication, the authenticator uses the private key to respond to a challenge, and the identity provider verifies the response with the registered public key. The user doesn't need to enter a conventional password.
Are passkeys the same as MFA?
→ No. Passwordless authentication describes how a user signs in without a conventional password. MFA requires multiple authentication factors according to the configured policy. A passkey can be used for passwordless login or incorporated into a multi-factor authentication flow.
What happens if a user loses their passkey?
→ The user needs a supported recovery path, such as another registered passkey or a secure account recovery process. The appropriate approach depends on the application's identity configuration. Developers should plan recovery before making passkeys the only available authentication method.
Is passwordless authentication more secure than passwords?
→ Passkeys can offer important security advantages over passwords, including resistance to common phishing attacks and the absence of a reusable password that can be stolen and replayed. The overall security of the application still depends on account recovery, session management, authorization, and correct implementation.
Final Thoughts
Passwordless authentication can simplify sign-in and reduce reliance on conventional passwords.
Passkeys offer a phishing-resistant approach, but a production-ready implementation still needs secure registration, account recovery, device compatibility, session handling, and authorization.
Managed Keycloak can reduce the burden of operating identity infrastructure.
Skycloak's passkey configuration gives developers a starting point for exploring this approach, while OIDC connects the identity provider to the application.
The goal isn't just to remove a password field. It's to make authentication easier for users without compromising security.
| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah |
  
|
|---|
Top comments (3)
passwordless authentication... I think this is what everyone on earth needs 😂
My biggest problem is choosing passwords and saving them.
Haha, honestly, the number of times we’ve all had to reset a password because we couldn’t remember it. And we don't need to mention what happens when we switch devices or lose access to one 😂 Passkeys could save us from so much of that headache!
Great explanation!
What do you think about OTP's ("one time passwords") as a password replacement, where you get a code (for one time usage only) emailed to you when you try to log in?
I'm not an auth/security expert, but I feel OTP's confer more or less the same advantages as passcodes, and are probably just as easy to use (actually I prefer them, to me they feel even easier than passcodes) ...
But I might be totally wrong, and passkeys might be vastly superior to OTP's - if so, please enlighten me!
(what I absolutely agree with though, is that both passkeys and OTPs are superior to passwords ... !)
P.S. okay, as always Google is your best friend:
"passkeys are phishing-resistant while OTPs can be intercepted"
Yeah I guess they have a point there ... and:
"Passkeys: Fast and simple. You log in using biometrics (Face ID, fingerprint) or a device PIN. No typing or waiting required"
Point is, for me this does not count as "fast and simple" - I intuitively dislike using face ID, fingerprint or other "biometric" stuff (might be irrational, but never mind, I just dislike it) - and needing a separate device for a PIN or code does not sound that "easy" to me, compared to just getting a code via email ...
Still according to Google:
"OTPs: Slower. You must wait for a text or email code, then manually type or copy a string of numbers"
Nah, does not bother me at all :-)
So I just see it the other way around - OTPs for me, from an "ease of use" point of view! But, I understand that from a security point of view they're the weaker solution ...