Still alpha after all these years
I have updated
WebAuthnLiveComponent with a new version which adds preliminary support for Passkeys. More specifically, discoverable credentials aka resident keys.
WebAuthnLiveComponent.PasskeyComponent is the module containing the new LiveComponent, which provides a drop-in pair of buttons for registration and authentication via Passkey in a LiveView application
PasskeyComponent, which in turn sends messages to the parent LiveView (see Communication).
Thanks to @dbern for moral support and asking great questions as I wrestled with implementing Passkey support. The mental model here is quite different from traditional authentication, so it was helpful to have someone to ask “how,” “why,” and “what if” throughout the process.
Split, merge, or ???
The full module name,
WebAuthnLiveComponent.PasskeyComponent is just a bit too much for my taste. I expect confusion about the two LiveComponents in this package, which are based on the same WebAuthn API, but take two approaches to implementation. The original component includes a form which requires a username before proceeding with registration or authentication.
So, I am looking for feedback on whether to split
PasskeyComponent into its own Hex package, replace the WebAuthnLiveComponent module with the Passkey implementation, or something else. I am inclined to keep the original component for applications which would like to require a username first, though I would plan on replacing the form with a slot and using a
@changeset assign to allow more control from the parent LiveView.
This is still an early alpha package with little adoption, but some excitement and interest expressed in this forum. So, there is still time to make significant changes to improve developer experience.
Speaking of Developer Experience
I spent some time documenting the
PasskeyComponent module, but there is still more work required to clearly document the process of using the component from start to finish. This includes adding the JS hook to the LiveSocket and several message handlers that must be added to the parent LiveView. Not to mention requirements for persisting the user’s public keys created during registration, as well as other requirements and best practices in the parent application.
Updates to the demo Phoenix application are a work in progress. With the Hex package updated, some cleanup needs to be done to remove prototype component code. Other updates to the demo app include:
- Finish Live Session Hook implementation
/passkey link to landing page
- Add tests for the
Auth LiveView and route
If you are interested in contributing, please don’t hesitate to respond in this thread. Since this is a potentially critical piece of security code, I believe it is important to keep the conversations as public as possible.