"No available authenticator recognized any of the allowed credentials" in iOS, even in example app

[cannikin]

Got my implementation working beautifully in Chrome and Safari on the desktop, no problems.

Moving to iOS (15.5), registration works, but when I go to authenticate I get No available authenticator recognized any of the allowed credentials my catch block around the startAuthentication() function. I thought maybe something about my specific implementation was messed up so I tried in the example app and I see the same thing:

Anyone else seen this?

[lmarschall]

What kind of authenticators are you using on desktop and on iOS? Maybe it‘s got something to do with the allowCredentials flag on the server side?

[cannikin]

On the desktop I have the authenticatorAttachment set to platform which means TouchID on my Macbook. Doing the same thing for my iPhone 13 means FaceID.

[MasterKale]

I think I know what's going on: Safari typically allows websites a single "freebie" indirect execution of WebAuthn. If there was any kind of asynchronicity before your call to one of the navigator.credentials then Safari would fail the API call right away with an inscrutable error message.

Fortunately sometime back in February Apple eased up on that, and now websites were more free to make API requests and perform other actions before ultimately calling WebAuthn, but only once for a given page load. After that you'd potentially have to reload the page to get WebAuthn to reliably trigger again.

I tested my example site on iOS too and no matter which button I clicked first, the first button would act as expected, while the second button would always error out in the same way you described. This is making me believe that you're describing that Safari limitation.

[cannikin]

Hmm, is there any workaround for that, then? This is in React, so there's potentially an infinite number of events before any WebAuthn invocation! startAuthentication() itself is async and wraps the calls to navigator, what are we supposed to do if you need to call navigator directly in an onClick?

[cannikin]

I noticed that as well...I saw something on Stack Overflow about using an onTouchStart instead of onClick? I didn't actually get a chance to implement that though. I wasn't sure if I was going to have to go down some rabbit hole of checking for user agent or some other method to determine whether to use onTouchStart or onClick depending on the browser/platform. :(

[MasterKale]

That doesn't sound like a solution at all, according to MDN the onTouchStart event is only supported on mobile 😂 😭

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/ontouchstart#browser_compatibility

[cannikin]

Here's another weird behavior...so when I get the "No available authenticator..." message, if I reload the page then the call to open the authenticator works fine (even when that call is not user-initiated, I have it fire off as soon as the page loads). I figured I could just catch that "No authenticator available" error and then location.reload(), easy peasy! But nope, I get in an infinite reload loop, it keeps triggering the error, which reloads the page, which triggers the error...

It seems like the reload itself needs to be user initiated, even if the call to start the auth process isn't?? I even tried making my fallback button that says "Open Authenticator" have an onClick={() => window.location.reload()} and it does the same thing, throws the error again. It's like the user has to click the "reload" button in the browser itself. This is the same behavior in iOS Chrome in addition to Safari.

What the hell is going on?

[cannikin]

More testing...if I open my login page with an <a> tag (causing a real page load, rather than letting React just move pages in and out of the history) then I get FaceID to launch! However, If I then log out and click the link again to go back to login, now it won't work (even though that click is causing a real page load again!). 🫤

[MasterKale]

Something something "user security" I suppose.

It seems like the reload itself needs to be user initiated, even if the call to start the auth process isn't?? I even tried making my fallback button that says "Open Authenticator" have an onClick={() => window.location.reload()} and it does the same thing, throws the error again. It's like the user has to click the "reload" button in the browser itself. This is the same behavior in iOS Chrome in addition to Safari.

I can see how they came to this conclusion, a malicious site could endlessly spam the user to complete WebAuthn if it somehow got access to the page (bad lib import, etc...) and could programmatically reload the page to try again if the user cancelled out.

This still makes it difficult to intuit what constitutes a sufficient "user gesture"...

[MasterKale]

I just converted this issue into a discussion since it's been confirmed to be a WebKit restriction on the use of WebAuthn.

[fromtexas]

Got the same problem. I changed fetch to XMLHttpRequest and the problem disappeared 🪄

[cannikin]

Oh snap really?? I just assumed fetch was a nicer abstraction over XMLHttpRequest...what'd you do about headers, credentials, etc?

[fromtexas]

XMLHttpRequest has boolean property withCredentials for credentials and also method XMLHttpRequest.setRequestHeader() for headers. But, I guess, axios would be better option than using raw XMLHttpRequest

[cannikin]

Oh snap just re-write my implementation to XMLHttpRequest and sure enough, iOS Safari is happy! Thanks so much for following up and posting in this thread! :)

[MasterKale]

I...I'm glad you found a solution but also horrified that you found this solution. So use of fetch() enforces the indirect user gesture requirement, but XMLHttpRequest doesn't?

I dunno that I'd build anything atop this knowledge, it sounds more like a bug than a feature 🤔

[cannikin]

😈