Hey it’s been a couple months since the latest progress update and commit. Wondering if this awesome project still has wings! i would love to implement passwordless auth to my projects someday using your package.
artokun
scoop
I want to chime in with a +1 as well and generally give some support and encouragement 
And show gratitude 
1
type1fool
Wondering if this awesome project still has wings!
Thank you I suppose an update would be appropriate.
By all means, feel free to try out webauthn_components now in a non-production environment. Feedback on documentation, the API, and the demo app would be great! If you have some familiarity with WebAuthn, you could even open an issue or PR if you have ideas for improvements.
Update
The development pause is a result of a few challenges:
- I had been waiting for Passkey support in 1Password (finally in beta).
- I hadn’t been working on any projects using Passkeys.
- There’s not enough time in the day.
Last weekend, I installed the 1Password beta and successfully added Passkeys for a few personal accounts to observe the user flow. It’s nice having Passkeys stored in a cross-platform virtual device, but not a hard requirement for supporting Passkeys in an application.
This weekend, I plan on adding Passkeys to a side project. As part of this process, I will be making improvements to the package as issues surface.
I just spent some time working on the Phoenix app generator (PR 5505), and have a better understanding of Mix.Task and Mix.Generator. This will help with building code generators for the various schemas and migrations. As a result, adoption should be much easier, especially for greenfield apps.
I’ll keep this thread updated as things change.
Btw, welcome to ElixirForum, @artokun! 
8
type1fool
Update
I have opened a draft PR which adds a task for generating the core modules required for WebauthnComponents.
https://github.com/liveshowy/webauthn_components/pull/49
This PR is focused on generating the following files:
- User schema, migration, and context
- UserKey schema, migration, and context
- UserToken schema, migration, and context
Some opinions and best practices are codified in the generated modules:
Ecto.ULIDis used as the primary key for each of the schemas.
- ULIDs are essentially sortable UUIDs, which prevent user enumeration without adding much complexity.
- Each context only interacts directly with one schema.
- This makes the contexts easier to read & maintain compared to combining them into one
IdentityorAuthenticationcontext.
Scope
To limit scope, I am also constraining the generators to work best with Phoenix apps with no existing authentication. It may be possible to add WebauthnComponents to apps with basic authentication (a la phx.gen.auth), but doing so seems quite complex.
User email confirmation is also out of scope for now.
Call for Feedback
Before I wrap up this PR and move on to generators for LiveView modules, I want your feedback.
- Do you see any typos or blatant errors?
- If these files were generated in a new application, would they be a good starting point?
- Do you like the general direction of the project’s generators?
- Is there a better name for the task than
wac.install?
I’ll take feedback in this thread, but I’d prefer comments on the PR, especially as comments on the files for anything wrong or confusing.
In the meantime, I will be adding test generators for the contexts so they can be deployed with confidence.
4
type1fool
Update
Version 0.5.0 has been released
This release adds a wac.install mix task, which will generate schemas, contexts, and migrations for the following schemas:
%User{}%UserKey{}%UserToken{}
Each schema has a corresponding context with CRUD functions, where each function is has some documentation and a typespec - except a few token helpers from phx.gen.auth, which were overlooked.
My hope is that this further simplifies the process of implementing Passkeys in new LiveView apps. The generator is a bit opinionated about id types. To prevent user enumeration while maintaining sortability, Ecto.ULID is used as the :id type on the schemas.
Also of note, *.get/2 functions return ok/error tuples, which may be a departure from other context modules in your existing app.
Thanks to @jc00ke for providing feedback on the templates PR.
8
type1fool
Update
Version 0.6.0 has been released
This release extends the new wac.install Mix Task to generate all the code required to implement Passkeys in a new LiveView application. Also, the TokenComponent has been removed in favor of cookie-based session storage.
The readme and other documentation has been updated, and setup should now be a much more streamlined process. Using wac.install, you no longer need to generate the LiveView or other code to get up and running. See the wac.install docs for available options.
Thanks to @oullette @sax @mward-sudo and everyone who’s provided feedback on this project.
End User Demo
State of Passkeys
Passkey support has been picking up steam, and I’m looking forward to Windows adding support for credential management across devices. Recently, Passkey support graduated out of beta for 1Password, my preferred credential manager. MacOS and Android users can use their platform-specific credential managers as well.
Next Steps
My next planned improvement is to add Telemetry events to the components and remove all calls to Logger, with the goal of improving observability.
I would also like to document the process of implementing WebauthnComponents in existing applications, but this is a daunting task. Providing step-by-step migration from basic auth or 0auth seems feasible, though guides for migrating from phx.gen.auth, Pow, and various packages may put too much burden on maintenance. If you have thoughts or would like to contribute, feel free to ping me here or in an issue.
11
Joep
type1fool
Update
Version 0.7.0 has been released, with one new feature and a bug fix.
- Now, WebauthnComponents supports Passkey autofill, which streamlines the authentication process for existing users.
- Migrations are now generated in a deterministic order, fixing a bug where the
userscould be generated after its dependent migrations.
Passkey Autofill
With the introduction of autofill, users will be presented with a Passkey prompt automatically after the authentication component is mounted. Previously, users would need to click the “authenticate” button first, often thinking the email field was also required. With autofill, users have a more seamless authentication experience. 
If a user has multiple accounts on an application, they will still be prompted to select the desired account.
Order of Migrations
Most of the templates and generators I created can be generated out of order, but migrations are an exception. Because migration files are generated with a timestamp and users must be created first, it’s important to create them in the correct order.
The migrations generator was using a plain Elixir map for its template files. Elixir maps are unordered, so the order of the keys in code are not necessarily the order they will be processed in Enum functions or for comprehensions. This is an oversight that catches me more often than I’d like to admit. 
The solution was to convert the template map into a Keyword list, which maintains the order of its keys (fix commit). Now, we can be sure that the users table is created before the user_keys and user_tokens tables which depend on it. 
Credits
Shout out to Daniel Pinheiro for introducing the autofill feature and to David Parry for reporting the migrations issue.
11
type1fool
Excellent! Thank you for writing and sharing the blog post. I will read it more deeply later, but at first glance it looks like you found implementation fairly straightforward aside from understanding UserToken and an origin issue. This is great to see. 
—-
I pushed an update to v0.8.0 at ElixirConf last week, and a more detailed post is overdue. Once life is done interfering with my plans, I will be posting that update and revisiting some improvements that have been deferred.
6