Passwordless Login with Keycloak: A New Era of Authentication
- Andreas Grill
- 20. Feb.
- 9 Min. Lesezeit
Aktualisiert: 10. März
Introduction
At open200, Keycloak is our first choice when it comes to identity and access management (IAM). As we develop applications for our clients, we integrate Keycloak to ensure a secure login process. We generally advise against creating your own login mechanism due to security concerns. Instead, we advocate for tried-and-true solutions like Keycloak. This not only offers a secure, audited solution but also provides ready-to-use features such as two-factor and multi-factor authentication (2FA/MFA) support.
In this blog post, we aim to spotlight an additional Keycloak feature designed to enhance both security and user experience: Passwordless Login or Passkeys. We will explore the benefits of passwordless authentication, the technologies behind it, and how to configure it in Keycloak. Additionally, we will discuss the challenges and considerations when implementing passwordless login in your applications.
The Problem with Passwords
Passwords have long been the cornerstone of digital security. While people are familiar with how they work, passwords come with significant drawbacks. They are something you know, making them susceptible to being written down, shared, or even stolen. Over the years, security recommendations have evolved to encourage longer, more complex passwords. However, this approach has its limitations. People often reuse passwords across multiple services, which becomes a significant risk if one service is compromised.
The challenges with passwords are manifold. They are often forgotten, leading to frequent password reset requests. Moreover, the complexity rules (including special characters, numbers, and a mix of uppercase and lowercase letters) make passwords hard to remember but not necessarily secure. Cybercriminals have become adept at using techniques like phishing, brute force attacks, and credential stuffing to exploit weak password practices.
Enter Password Managers and 2FA
Password managers have been a partial solution, helping users create and manage unique passwords for different services. These tools can generate, store, and autofill passwords, reducing the cognitive load on users. However, adoption rates are still low, at around 30%, according to surveys by password manager company Bitwarden (accessed January 24, 2025).
Two-factor and multi-factor authentication (2FA/MFA) have also improved security by adding an extra layer of verification. These methods typically involve something you know (a password) and something you have (a mobile device or hardware token). While effective, these methods can sometimes degrade the user experience, requiring users to switch between devices to complete the authentication process. For instance, receiving a one-time password (OTP) via SMS or an authentication app can be cumbersome and time-consuming.
The Promise of Passkeys
Passkeys promise a fast, simple, and secure approach to authentication. They are not something you know but rather something you have. Passkeys are cryptographic keys that generate unique credentials for each authentication attempt.
This means that not only does every service use different credentials, but also every login attempt. This makes it much harder for passkeys to be phished.
Passkeys can either be device-bound or synced. Device-bound passkeys are stored on a specific device, such as a smartphone or a hardware token. Synced passkeys are typically stored in cloud keychains such as Apple's iCloud or Google's Chrome Profile and can therefore be accessed from multiple devices.
Passkeys are well-supported by modern browsers and operating systems, providing a seamless user experience.
Underlying Technologies
WebAuthn is a standard of the W3C and FIDO Alliance that defines how passkeys work. It uses asymmetric cryptography, involving public and private keys to sign challenges or encrypt data. WebAuthn describes two main procedures: device registration and authentication.
Before we dive into the technical details, let's take a look at the terminology:
Relying Party (RP): The entity that utilizes WebAuthn to register and authenticate users. In our case, this would be Keycloak.
Authenticator: The device or service that generates and stores the cryptographic keys. We differentiate between platform authenticators (e.g., the operating system) and roaming authenticators (e.g., a hardware token, a smartphone via QR Code).
Client: The user's device that interacts with the RP and the authenticator.
Credential Storage Modality: Describes the way an authenticator is able to store the user's credentials. It has a client-side credential storage modality if the credentials are stored in persistent storage on the client device, and a server-side credential storage modality if the credentials are encrypted (wrapped) and stored by the RP. Client-side credential storage modality is also called a resident key or discoverable credential and allows for usernameless authentication. Server-side credential storage modality allows for passwordless authentication.
Device Registration
A user can usually register multiple devices with a relying party. For instance, a user can register a laptop with a platform authenticator and a hardware token with a roaming authenticator. They can then choose which device to use for authentication.
Device registration can happen during the initial user registration process, or later when the user decides to enable passwordless login. Keycloak supports both scenarios.
When a user registers a device, the authenticator generates a key pair (public and private keys). The public key is sent to the relying party (in this case, Keycloak) and stored for future reference. The private key can either be stored on the authenticator or sent to the relying party—this depends on the credential storage modality. If the private key is sent to the relying party, it is encrypted with a master key that is stored or managed by the authenticator. The RP never has access to the private key.
The authenticator plays a vital role in safeguarding the private key, which is essential for the security of the entire authentication process. It must reliably store the private key and prevent unauthorized access. We will showcase some authenticators later in this blog post.
How Authentication Works under the Hood
The basic flow of authentication is as follows: When a user attempts to log in, the relying party sends a challenge to the user's device. The authenticator uses the private key to sign this challenge, and the signed challenge is sent back to the relying party. The relying party then verifies the signature using the stored public key.
Authentication with server-side storage:Â Keycloak sends the credential ID to the browser. But Keycloak needs to know the user beforehand. So we need to provide the username to Keycloak. The browser then forwards the credential ID to the authenticator. The authenticator tries to decrypt the credential ID with the master key. If it succeeds, it sends the credential ID to the relying party. The relying party then verifies the credential ID and the challenge.
A major advantage of this method is that the authenticator doesn't need to save service-specific data. The downside is that the username must be provided to the relying party, enabling passwordless authentication but not usernameless authentication.
Authentication with client-side storage:Â Keycloak now sends empty credential IDs to the browser (along with the relying party ID). The authenticator uses the relying party ID and provides keys to the browser. The user can then choose which key to use. After selecting the key, the authenticator signs the challenge with the private key of the selected key. The signed challenge is then sent to the relying party. The relying party then verifies the signature using the stored public key.
This method has the advantage that the relying party doesn't need to know the user beforehand. One drawback is that the authenticator needs to store service-specific data. However, this enables usernameless authentication and improves the user experience.
Are Passkeys Usernameless or Passwordless?
The FIDO Alliance defines passkeys as usernameless with discoverable credentials.
However, others also define passkeys as passwordless. So, there might be some confusion about the terminology.
As of version 26.1, Keycloak doesn't fully support usernameless authentication, but preview features, such as the WebAuthn Conditional UI, are available. Passwordless authentication, on the other hand, is already supported in Keycloak. At open200, we’ve used passwordless authentication on our Keycloak instance since 2024 with great success. More about this in the next section.
Passwordless Login at open200
At open200, we'd been using Keycloak with an LDAP-backed user federation for years; we've switched to fully Keycloak-managed users. We've also been gradually transitioning legacy systems to OIDC via Keycloak, so we can take advantage of single sign-on, 2FA/MFA, and passwordless login. When passwordless login became available, we decided to enable it as an opt-in feature for our users. However, we still allow users to use their passwords with 2FA/MFA if they prefer. To achieve this, we had to adjust Keycloak's browser flow.
Passwordless or Password with 2FA/MFA
Users can register their devices for passwordless login in the Keycloak account console, linking their accounts to passwordless authentication methods. These can be managed in the admin console alongside other user credentials, such as 2FA/MFA options.
When a user logs in, they must first provide their username. If they have registered a device for passwordless login, they can opt to log in with passwordless authentication and proceed using their authenticator. However, Keycloak also allows users to switch to password login with 2FA/MFA credentials if they prefer.
We implemented this feature by adjusting the browser flow in Keycloak. We created a duplicate of the original browser flow and made the following changes:
We added a required Username Form to the top-level "forms" flow, requiring users to provide their username first.
We also added a required subflow to the same "forms" flow, which we call "Passwordless Or Password +2F."
In the subflow, we created two alternative steps:
The first alternative step is "WebAuthn Passwordless Authenticator," which handles passwordless login if the user has registered a device.
The second alternative step is a subflow called "Password + 2F," which is similar to the original "Forms" flow, but with the Username Password Form removed and replaced with a Password Form.
Our Findings
We identified several key findings when implementing passwordless login with Keycloak:
Passwordless Login: Passwordless login is a secure and user-friendly authentication method that some of our users have already incorporated into their workflows. We've found that users who have registered a device for passwordless login tend to prefer it over traditional password login.
User Experience: The user experience of passwordless login is excellent. Users can log in with a single click, and the login process is fast and secure. We've received positive feedback from users who have enabled passwordless login.
User Adoption: While passwordless login is more secure and user-friendly, some users might be hesitant to switch from passwords to passkeys. Having an authenticator with good browser or operating system integration can make the transition smoother. We've addressed this by providing clear instructions and support for users who want to enable passwordless login. For the time being, we are not forcing users to use passwordless login, but we are encouraging them to do so.
Mixing Passwordless and Password Login: Our adjusted browser flow works well for our use case, but we encountered an issue when allowing password login as a fallback method. If you don't use a user federation like LDAP as you may need to manually set the priority of the credentials in the Admin Console or via the REST API. At the moment, there is no central configuration to prioritize passwordless login over the traditional password flow; however, we think that future Keycloak Passkey features will address this issue.
Password Managers: Passkeys don't replace password managers for our users, but they can work well together. Some of our passwordless users use them in combination with their password manager. More and more password managers have great support for passkeys and act as authenticators.
Fallback Authenticators: Registering multiple authenticators is a great way to ensure you have access to your account, even if you lose a critical device, such as your laptop. For instance, you could always register a fallback authenticator on your phone or YubiKey that you can use to log in to your account, even if your main device is not available.
What's Next?
Keycloak has a preview feature called "passkeys", which enables the WebAuthn Conditional UI for usernameless login. We've been testing the feature and are excited about the possibilities it offers. With this feature it's possible to simply select a predefined passkey including the username when logging in. That means, you no longer need to manually provide the username first, but simply select the passkey from the registered authenticators. We believe this enhances the user experience over passwordless authentication. We plan to enable this feature for our users once it's stable and fully supported in Keycloak. At the moment, Keycloak won't allow us to have it as the default login method with password login as a fallback, but we hope that this will be possible in the future.
More and more users are adopting passwordless login, especially since we recently enforced 2FA/MFA for all users. We believe that passkeys and usernameless login will become the standard in the future, and we are excited to enhance the security and user experience of our applications.
Conclusion
Passwordless login with Keycloak offers a secure, user-friendly alternative to traditional password-based authentication. By leveraging passkeys and WebAuthn, users can enjoy a seamless login experience that enhances security and convenience. While there are challenges and considerations when implementing passwordless login, the benefits far outweigh the drawbacks. At open200, we have successfully integrated passwordless login into our Keycloak setup and have seen positive results in terms of security, user experience, and adoption rates.
If you're considering implementing passwordless login in your applications, we recommend exploring the features and capabilities of Keycloak and Passkeys. If you have any questions or need assistance with setting up passwordless login, feel free to reach out to us. We're here to help you navigate the world of secure authentication and identity management.