Requiring "native click listener" within LiveView for webauthn

Hey there, this piqued my curiosity…

So after a bit of research, I came across this pretty helpful section on “Propagating User Gestures” in a post from WebKit themselves. It covers why they require user gesture detection and then a few different approaches to handling it:

• Calling the API Directly from User Activated Events
  (note: no propagation necessary when buffering the challenge before the onclick event)
• Propagating User Gestures Through XHR Events
• Propagating User Gestures Through Fetch API
• Easter Egg: Propagating User Gestures Through setTimeout

source: Meet Face ID and Touch ID for the Web | WebKit

A simple path forward could be writing a client side hook with a mounted callback that “optimistically” fetches the challenge (via websockets) to buffer it on the client as well as manually add a click event listener to call the WebAuthn API (via http).

# here's some pseudocode

<button id="webauthn" phx-hook="WebAuthn">

def handle_event("fetch-challenge", _params, socket) do
  # optimistically generate challenge
  {:reply, %{challenge: "bufferedChallenge"}, socket}
end

Hooks.WebAuthn = {
  mounted(){
    this.pushEvent('fetch-challenge', {}, (reply) => {
      if (reply.challenge) {
        console.log("here's the challenge to buffer", reply.challenge);
        // buffer challenge on the client
      }
    });

    this.el.addEventListener("click", async (event) => {
      const options = {
        publicKey: {
          ...
          challenge: challengeBuffer, // retrieve buffered challenge
          ...
        }
      };
      const publicKeyCredential = await navigator.credentials.create(options);
    })
  },
}

Thanks so much for the reply. I was away from this a bit but finally got back to it and thanks to your reply as well as some help in the elixir slack channel I was able to get it working!

One question though, in my implementation I don’t prefetch the challenge and only do it on the user action. Is this just a performance optimization or is there more to it?

That’s a good question, I gravitated towards pre-fetching because I figured it was simpler to reason about (for the hypothetical future me/others) since it gets rid of the need for propagating user gestures to begin with. Also, the WebKit post mentioned pre-fetching is required to support iOS/iPadOS 14.

On iOS 14, iPadOS 14 and macOS Big Sur Beta Seed 1, only the very first case is supported. Thanks to early feedback from developers, we were able to identify limitations and add the later cases.

It did cross my mind that there could be some upside for clients stuck on slow connections where pre-fetching from the server would help the flow be more responsive – plus LiveView makes that pretty straightforward so why not ¯\_(ツ)_/¯.

Anyway, it’d be nice to see what you came up too!