Instructions

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates

At the Denver Elixir meetup, one of the attendees (@RGENT) raised a concern about token security (video link).

In short, the token saved in sessionStorage may be accessed by 3rd party JS dependencies. Suggested mitigations include cookie storage and/or adding content security policy (CSP).

Because these component interact exclusively via WebSockets, cookies may not be an option here. CSP is likely the better solution, though other alternatives may exist.

Resources

• Google Search "sessionstorage security"
• Okta Blog: Secure Browser Storage: The Facts
  • See section on Web Workers
• CredentialsContainer.store() (MDN) 🤩
• CredentialsContainer.preventSilentAccess() (MDN)

Acceptance Criteria

• Must run mix hex.outdated to list outdated deps
• Must update Phoenix LiveView to 0.18.x
• Must update Wax to latest version
• May update other pkgs

https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredentialCreationOptions

Testing on various devices, the passkey was not saving.

Problem fixed by changing requireResidentKey: true to residentKey: 'required'.

I will fix this one too.

Is your feature request related to a problem? Please describe.

I'm always frustrated when I need to input again and again my email when I need sign-in. Enabling Passkey Autofill with mediation: "conditional" and autocomplete="username webauthn" on email input, helps that.

Describe the solution you'd like

Implements Conditional UI to enable Passkey autofill

Additional context

Sign in with a passkey through form autofill
Add passkeys to the browser autofill
Explainer: WebAuthn Conditional UI

Notify

• @type1fool

Acceptance Criteria

• Must add Passkey Component
• Must add Passkey JS hook
• Must allow user to register or authenticate without entering username/email/password

Resources

• Wax Docs
• MDN Docs

Description

The handle_info of :registration_successful trusts the assigned form value of the email. The email could be changed during the WebAuthn flow.

Steps To Reproduce

Steps to reproduce the behavior:

1. Visit http://localhost:4000/sign-in
2. Enter [email protected] into the email input.
3. In console, run this JS:

function changeEmail() {
  var emailInput = document.getElementById("email")
  emailInput.value = "[email protected]";
  emailInput.dispatchEvent(new Event("input", {bubbles: true}))
}

setTimeout(changeEmail, 10000);

4. Click "Sign Up".
5. Wait at most 10 seconds for the email input to change (because of JS from step 3).
6. Complete the sign up flow successfully.

Expected behavior

The difference in the form email and the email of the created passkey should cause user creation to fail.

Suggestion

Pass the email back as part of the :registration_successful payload and check that the form email matches exactly.

I do not think this is a realistic attack vector for any serious system. Email confirmation should be done after creating the passkey.

Instructions

https://github.com/actions/setup-elixir

Acceptance Criteria

• Must build the application
• Must run tests & credo checks
• Must cache compiled files upon success
• Must deploy release to Hex (docs)

Description

The 0.6.3 update (diff) (PR) introduced a bug with the origin configuration.

It appears that by using the socket's host_uri, Wax's rp: :auto results in a mismatch, which prevents a valid credential from being used during authentication.

Is your feature request related to a problem? Please describe.

I've found this library to be a great start to adding passkeys to my application, but specific implementations make it challenging to add as-is. The token component is great, but when I have push navigation the current setup means that I have to check in all of my handle_params as well as all of my handle_event callbacks to know whether a user is already loaded, and every single live view I make needs to copy the same 3+ handle_info callbacks in order to work.

This might be more for the example repo than for the library itself, but if the hooks were broken apart a bit more it might be more clear how to use connect params to load a user in on_mount.

Describe the solution you'd like

• Break out at least one utility function from the token hook, for getting and setting the session token.
• (maybe) split the token component into two, one of which handles logout. This would mean that logged-in liveviews would only need to implement callbacks for token deletion, rather than all token callbacks.

Describe alternatives you've considered

I've instead used this library as a reference for writing my own components and hooks. If you find security issues or more complete integration code, I'll need to follow your fixes and apply them to my code.

Additional context

This is great work! It and your conference presentation were really helpful for me to add passkey support to my app.

Often, a user may want to register additional keys after creating an account for backup or survivorship purposes. The Passkey package should provide an API for registering additional keys when an application wants to support this feature.

Acceptance Criteria

• Must add SecondaryPasskey LiveComponent
• Must pass user.id & user.displayName to handlePasskeyRegistration in passkey_hook.js
• Must update demo app to illustrate component usage
• TBD

I believe the two mix commands in README.MD to generate the database structures should be using mix phx.gen.context rather than ecto.gen.migration

With discoverable credentials, username and email data is not required up front. And, schemas for UserKey, UserToken, and UserProfile may differ in surprising ways from traditional applications.

So, custom generators may helpful for developers implementing Passkey support for the first time.

Acceptance Criteria

• Must interpolate app and module names
• Must generate Users context
• Must generate User schema
• Must generate UserKeys context
• Must generate UserKey schema
• Must generate UserTokens context
• Must generate UserToken schema
• Must generate context tests
• Must document considerations and customizations

Bonus

• If user schema already exists, prompt for appropriate action
  • For now, it may be wise to only allow the generator to run when there is no existing auth code.

User Story

As a user of this component, I would like to provide my own changeset from my custom LiveView and see the form render fields based on the changeset's required fields.

Acceptance Criteria

• Must define new changeset prop of type struct
• Must define default changeset
• Must list required fields and their types
• Must generate form fields based on changeset fields and types

The title says it all. I think the AuthenticationLive module should be split up.

The main reason is for ease of modification, then, I guess "separation of concerns".

I started implementing a 3rd flow for users to create a passkey for an existing account using email confirmation link, and quickly saw I would be using the RegistrationComponent for something that is not registration. That was problematic because the event-passing does not refer to the component ID or some other unique identifier. If they were in separate LiveViews, this would not be a problem.

On that note, I would also suggest renaming this to something more explicit like PasskeyCreationComponent, since it does not actually know or care about users being registered, only passkeys being created.

Any thoughts are welcome, I am recording "milestone" decisions that will be reflected in my future PR that will have split LIveViews, no user ID in the session and (hopefully) a "lost device" flow.

As of v0.6.0, WebauthnComponents can be used to easily scaffold Passkey authentication in new Phoenix apps. For existing applications with password-based authentication or 0Auth, more extensive documentation is needed.

Update JS hook to use handleEvent instead of creating and removing event listeners.

https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#push_event/3

Acceptance Criteria

• Must namespace events with webauthn.* (ie webauthn.registration_challenge)
• Must replace window event listeners with handleEvent

LiveView.attach_hook/4 may allow for some code in the generated LiveView modules to be streamlined.

https://hexdocs.pm/phoenix_live_view/0.20.0/Phoenix.LiveView.html#attach_hook/4

To support multiple keys for user accounts and MFA usage, and to separate concerns, the components need to be split up.

Acceptance Criteria

• Must move registration to new RegistrationComponent
• Must move authentication to new AuthenticationComponent
• Must move token to new TokenComponent
• Must move support to new SupportComponent
• Must move registration to new registration_hook.js
• Must move authentication to new authentication_hook.js
• Must move token to new token_hook.js
• Must move support checks to support_hook.js
• Must remove PasskeyComponent

Context

• Elixir Forum post

Instructions

https://hex.pm/docs/publish

Assigning and authenticating users with tokens in LiveView is a tedious process to implement. If possible, a generator for LiveView on_mount hooks would help developers get up to speed quickly, assuming requirements are met (see #15).

Acceptance Criteria

• Must raise if User, UserKey, UserToken, or UserProfile schemas don't exist
• Must generate :assign_user hook
• Must generate :require_user hook
• Must document considerations and customizability

The session can be modified client-side and what is generated here makes it too easy to trust that the user_id in the session is trustworthy.

Acceptance Criteria

• Must add new button type=button
• Must be labeled "Sign in with Passkey"
• May use key icon (mini variant)

Resources

• Heroicons
  • Options: finger print, key*, cloud, face smile

In the session.ex controller, supplant usages of clear_session with this function copied from phx.gen.auth:

  # This function renews the session ID and erases the whole
  # session to avoid fixation attacks. If there is any data
  # in the session you may want to preserve after log in/log out,
  # you must explicitly fetch the session data before clearing
  # and then immediately set it after clearing, for example:
  #
  #     defp renew_session(conn) do
  #       preferred_locale = get_session(conn, :preferred_locale)
  #
  #       conn
  #       |> configure_session(renew: true)
  #       |> clear_session()
  #       |> put_session(:preferred_locale, preferred_locale)
  #     end
  #
  defp renew_session(conn) do
    conn
    |> configure_session(renew: true)
    |> clear_session()
  end

Description

Migrations are generated out of correct order, with the users table created after the migrations that depend on them.

Steps To Reproduce

Steps to reproduce the behavior:

1. Run mix wac.install on a newly-generated Phoenix app, using Elixir 1.15.x.
2. Generated migrations will (sometimes?) appear with the users table generated after the associated tables that require foreign key associations to that table. See listing:

priv/repo/migrations
❯
ls
.rw-r--r--  52 djp staff 2023-11-28 11:38 .formatter.exs
.rw-r--r-- 667 djp staff 2023-11-28 11:42 20231128004224_user_keys.exs
.rw-r--r-- 461 djp staff 2023-11-28 11:42 20231128004225_user_tokens.exs
.rw-r--r-- 300 djp staff 2023-11-28 11:42 20231128004226_users.exs

4. Run mix ecto.migrate.
5. See error:

mix ecto.migrate
Compiling 15 files (.ex)
Generated example app

11:42:39.934 [info] == Running 20231128004224 Example.Repo.Migrations.CreateUserKeys.change/0 forward

11:42:39.935 [info] create table user_keys
** (Postgrex.Error) ERROR 42P01 (undefined_table) relation "users" does not exist
    (ecto_sql 3.11.0) lib/ecto/adapters/sql.ex:1054: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (ecto_sql 3.11.0) lib/ecto/adapters/sql.ex:1161: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.11.0) lib/ecto/migration/runner.ex:348: Ecto.Migration.Runner.log_and_execute_ddl/3
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (ecto_sql 3.11.0) lib/ecto/migration/runner.ex:311: Ecto.Migration.Runner.perform_operation/3
    (stdlib 3.17.2.4) timer.erl:166: :timer.tc/1
    (ecto_sql 3.11.0) lib/ecto/migration/runner.ex:25: Ecto.Migration.Runner.run/8

Expected behavior

users table should always be created first.

AdditionalCcontext

Elixir 1.15.7
Erlang 24.x

Notify

• @type1fool
• @suranyami

Description

Running into issues where I can't use this on Safari. Both iOS and MacOS versions fail with different error messages.

On iOS I get a flash message when I go to the sign-in route that says "Passkeys not supported on this browser."

On MacOS I get errors in the console:

[debug] HANDLE EVENT "register" in MyPkAppWeb.AuthenticationLive
  Component: WebauthnComponents.RegistrationComponent
  Parameters: %{"value" => ""}
[debug] Replied in 542µs
[debug] HANDLE EVENT "error" in MyPkAppWeb.AuthenticationLive
  Component: WebauthnComponents.RegistrationComponent
  Parameters: %{"message" => "This request has been cancelled by the user.", "name" => "NotAllowedError", "stack" => ""}
[debug] Replied in 107µs
[warning] [unhandled_message: {MyPkAppWeb.AuthenticationLive, {:error, %{"message" => "This request has been cancelled by the user.", "name" => "NotAllowedError", "stack" => ""}}}]

To end on a positive note - both Firefox and Chrome on MacOS works as expected and across browsers! UX is 👌

Steps To Reproduce

Steps to reproduce the behavior:

1. Instantiate a new Phoenix project
2. Add deps
3. Install deps and run ecto.create
4. Run wac.install
5. Start server
6. Go to /sign-in
7. Enter an email
8. Click Sign Up button.

Expected behavior

I should be able to sign up and login like on Chrome and Firefox.

Desktop (please complete the following information)

• OS: iOS, MacOS
• Browser: Safari
• Version: 17.3.1

Smartphone (please complete the following information)

• Device: iPhone 15 Pro Max
• OS: iOS
• Browser: Safari
• Version: 17

AdditionalCcontext

Add any other context about the problem here.

Notify

• @type1fool
• @kevmodrome

Acceptance Criteria

• Must add :telemetry as a dependency
• Must emit events from PasskeyComponent
• May remove calls to Logger

Instructions

https://hexdocs.pm/phoenix/telemetry.html

Instead of setting the token in JS SessionStorage, add a session controller which saves the token in a cookie.

This may eliminate the need for connected?(socket) checks.

Update the demo app to test & document usage.