Add support for passkeys/webauthn

[arosenb2]

As additional support is being added daily, it seems like it would be a great step forward to add first-class support for passkeys instead of just TOTP

Recent articles have shown some approaches for Elixir/Phoenix (and to be fair, it does require a lot of JS) but the BE portion seems like it could become a built-in login strategy.

Example: https://til.verschooten.name/til/2024-09-07/passkeys

[zachdaniel]

Would love to work in @type1fool's webauthn components directly for that strategy. We could support it in our builtin UIs automatically.

[arosenb2]

I think it would be beneficial to also support a headless mode for it (for example, a native app with an Elixir+Ash backend API)

[zachdaniel]

For sure, everything in ash_authentication already does that, we just provide pre-built UIs for convenience with LV.

[type1fool]

It would be nice to see webauthn_components integrated with Ash! I opened issue #84 for this on the WAC repo, and I may be able to tackle it by end of the year.

[jpease]

Just throwing my hat in that I'd love to see this too!

[jimsynz]

This is definitely on my todo list but I need to get my head around the passkeys mechanism better before I even think about building it out

[jimsynz]

I'm keen to hear how other folks would go about tackling it.

[jimsynz]

Here is a robotically proposed implementation plan:

Strategy Module: AshAuthentication.Strategy.WebAuthn

Server-Side Requirements:

• Generate and validate challenges (random 32+ bytes)
• Store per-user credentials:
  • credential_id (binary, unique)
  • public_key (binary, COSE format)
  • sign_count (integer, for cloned credential detection)
  • transports (array, optional)
• Registration flow:
  • Begin: generate challenge, return options
  • Complete: verify attestation, store public key
• Authentication flow:
  • Begin: generate challenge, return options with allowed credentials
  • Complete: verify signature against stored public key, check sign_count
• Verification: decode CBOR, validate clientDataJSON origin/challenge, verify signature

Client-Side (LiveView Integration):

• JavaScript hook for navigator.credentials.create/get
• Handle ArrayBuffer ↔ base64 conversion
• Push events back to LiveView with serialized credentials
• Error handling for browser support/user cancellation

Dependencies:

• CBOR decoding library (attestation/authenticator data)
• COSE key parsing
• Crypto verification (ECDSA/RSA signatures)

Configuration Options:

• rp_id - relying party ID (domain)
• rp_name - display name
• authenticator_attachment - "platform" | "cross-platform" | nil
• user_verification - "required" | "preferred" | "discouraged"
• attestation - "none" | "direct" | "indirect" (usually "none")
• timeout - milliseconds

Testing Considerations:

• Requires browser automation (Wallaby/Playwright)
• Virtual authenticator API for testing
• Mock credential generation for unit tests

Related:

• Optional: Discoverable credentials (resident keys) for username-less auth
• Optional: Credential management UI for users to view/delete passkeys

[simpers]

I'm very keen on this, and my main goal is the username-less auth.

I have a branch and I have done some scaffolding already, with some tests setup and whatnot, in this repo. I have not at all started on the AshAuthenticationPhoenix parts yet, and for that I'd want to bounce with some of you on how to approach it.

Just earlier today I noticed a (private?) message thread by the author of WebAuthnComponents, including some others, about the future of that library as well as the possible integration with AshAuthentication. I had previously expressed interest in helping out with this and reached out to him to see what his thoughts were.

Now I will try to get the core of it working in AshAuthentication, and it is to me a high-priority thing.. I just hope to be able to get enough time to do it. Then I'll start on the Phoenix stuff, but I don't know yet which route to go there as WebAuthnComponents is essentially a project to generate files for you, so I don't yet know how to hook into the AshAuthenticationPhoenix stuff and whether it is put the views there or not now in the MVP.

Configuration Options:

* `rp_id` - relying party ID (domain)

* `rp_name` - display name

* `authenticator_attachment` - "platform" | "cross-platform" | nil

* `user_verification` - "required" | "preferred" | "discouraged"

* `attestation` - "none" | "direct" | "indirect" (usually "none")

* `timeout` - milliseconds

What affects would multi-tenancy have on this, as Ash currently supports it?

I'm considering cases where you have different relying parties going through the same service, and what kinds of configurations would affect this.

One use-case is that I have multiple domains where my admin accounts could access all domains, but where each user of each domain can only access their own, and so on. 🤔

[zachdaniel]

What affects would multi-tenancy have on this, as Ash currently supports it?

Ultimately you'd need to consider a case where users want authentication to be per-tenant or external to tenants. Not sure its reasonable to support it in a "mixed" way for a single flow, but probably not?

[raul-gracia]

I've been working on this and have two draft PRs up:

• ash_authentication: feat: add WebAuthn/Passkey authentication strategy #1144: the core WebAuthn strategy
• ash_authentication_phoenix: feat: add WebAuthn/Passkey Phoenix components ash_authentication_phoenix#718: LiveView components (registration form, sign-in form, credential management)

The strategy follows the same pattern as Password: DSL entity, Transformer, Verifier, Actions wrapping wax_ for FIDO2 ceremonies, Plug for HTTP, and a Strategy protocol implementation. Credentials get stored in a user-defined Ash resource (similar to how TokenResource works).

Some things that came up while building this:

Multi-tenancy (@simpers you asked about this): rp_id, rp_name, and origin all accept MFA tuples so you can resolve them per-tenant at runtime, e.g. rp_id {MyApp.WebAuthn, :rp_id_for_tenant, []}. Covers the case where different domains go through the same service.

Origin vs rp_id: this one bit me. The browser includes the port in the origin (https://localhost:4001) but rp_id is domain-only (localhost). Added a separate origin DSL field for this. Without it, dev on non-standard ports breaks silently.

Credential management: list, rename, delete (with a guard so you can't delete your last key), and add-credential for adding a second key to an existing user. register creates a new user, so adding keys to existing users needed its own add_credential action.

Testing without browser automation: we generate valid WebAuthn attestation/assertion data programmatically using EC key pairs and CBOR encoding. 43 tests covering the full Wax pipeline, no browser needed.

I also put together a demo app for manual browser testing: https://github.com/raul-gracia/webauthn_demo registration, sign-in, credential CRUD, all working with Touch ID and Chrome's virtual authenticator.

wax_ is an optional dep so it doesn't add install weight for users who don't need WebAuthn.

Happy to get feedback on the approach.