Introduction
Due to the fast adoption of passkeys & WebAuthn, the concept of non-resident keys has been increasingly discussed. Understanding the challenges and solutions associated with non-resident keys is crucial for software developers and product managers to provide user-friendly authentication systems. Especially when it comes to the combination with Conditional UI in passkey scenarios with Conditional UI. Then, it’s essential to understand which WebAuthn server settings should be in place.
Understanding Non-Discoverable Credentials
Non-resident keys, also known as non-discoverable credentials, are cryptographic keys that are not stored on the authenticator device. Instead, they rely on a generated key pair linked to the user’s account on the server side. This approach ensures that the key is temporarily stored in the authenticator’s protected memory, earning it the nickname “ephemeral key.” The reliance on non-resident keys, especially in multi-device scenarios, can complicate the authentication process, potentially degrading the user experience if not properly managed.
The WebAuthn Server Configuration Dilemma
The configuration of the WebAuthn server plays a critical role in managing non-resident keys effectively. Two primary scenarios emerge based on how the server handles the allowCredentials parameter: providing specific credential IDs for authentication or leaving the array empty for a more flexible authentication approach. Each method has its implications for user experience.
Challenges with Conditional UI and Non-Resident Keys
The adoption of Conditional UI, which aims to streamline the authentication process by autofilling or eliminating the need for usernames, introduces additional complexity. This feature is particularly problematic for non-resident keys, as they require explicit credential IDs for authentication, contrasting with the seamless experience desired with Conditional UI. Balancing the needs for security and user convenience becomes a delicate act, necessitating a nuanced approach to server configuration and authentication flows.
Recommendations for WebAuthn Server Implementation
For developers aiming to accommodate both Conditional UI and non-resident keys, a few strategies are recommended. Distinguishing between Conditional UI logins and regular WebAuthn login attempts is crucial. This differentiation allows the server to appropriately manage the allowCredentials parameter, ensuring a smooth authentication process regardless of the key type. Providing all relevant credential IDs for users with non-resident keys while allowing flexibility for Conditional UI scenarios ensures both security and user satisfaction.
Conclusion: Striking the Right Balance
The successful integration of WebAuthn and the management of non-resident keys require careful consideration of both technical and user experience factors. By adhering to best practices for WebAuthn server configuration and understanding the intricacies of non-resident keys and Conditional UI, developers can create secure, user-friendly authentication systems. While this summary provides an overview, delving into the detailed recommendations and insights available on our full blog offers a deeper understanding crucial for effective implementation.
Top comments (1)
What I don't understand is your assumption that you have to try the credentialIds one by one. That's simply technically wrong. As a relying party, you can simply return the array of allowed credentials. During assertion in the browser, it will be successful if any of those match. Check it out if you want, go to passwordless.id then sign up with your pc then register a second device like your phone, it will work seamlessly with both. PS: Please don't take it the bad way, I just wanted to avoid possible confusion in this already greatly complex topic.