Requiring "native click listener" within LiveView for webauthn

Elixir Framework Forums Livebook Forum
, , ,
1

Hi all! I am working on an implementing webauthn and passkeys for a little side project of mine. The issue I am seeing is Safari specifically has two requirements for authn calls:

  1. Webauthn must be called in a native click listener (user gesture detection)
  2. Safari only supports the use of XHR and fetch within native click handlers for requesting WebAuthn registration and authentication options.

Right now I have a phx-click handler on a button that a push_event to a javascript hook I have registered on the socket. I don’t know javascript well but know what I have currently doesn’t satisfy the two requirements above but unsure how to proceed. I’m curious if anyone has any insight into what a “native click listener” is and if we can meet that requirement in LV? And for #2 it sounds like the pushEventTo javascript function won’t work. I am starting to think I will need to do much of the auth flow over http. Would love any thought, thanks!

2

:wave:t3: 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);
    })
  },
}
2 Likes
3

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?

4

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!

1 Like