Safari 15.5 not working

[masteratt]

Hello,

If you go to your website on Safari 15.5 and try to register and login: https://fido2-net-lib.passwordless.dev/passwordless#heroFoot

Registering works but sign in fails:

Apple did make a change regarding WebAuthn as follows for Safari 15.5:
"Fixed WebAuthn implementation to match specifications to use the default pubKeyCredParams list if the list in makeCredential is empty."
https://developer.apple.com/documentation/safari-release-notes/safari-15_5-release-notes

However, our pubKeyCredParams list is not empty so I don't know why the behaviour is broken all of a sudden.

Is there any changes I can make in my options or when I call this library that will fix this issue?

What complicates matters is I don't have access to Safari 15.5 so I can't do further debugging so thought I'll try here to see if you knew of this breaking change and had any ideas.

Many thanks.

[aseigler]

I have pretty close to the same problem working with the new Safari versions with roaming authenticators, forget about platform authenticator. It's definitely the client side stuff, javascript and platform, it's not even getting far enough to be server related. Not real sure what the issue is honestly.

[dIeGoLi]

The problem is following:

[Warning] User gesture is not detected. To use the WebAuthn API, call 'navigator.credentials.create' or 'navigator.credentials.get' within user activated events.

Safari wants to associate a user gesture in order to allow to interact with navigator.credentials. Apparently using the fetch API looses this association in the continue action. Using jquery ajax call on the other hand does not lose that association. I can't discuss on why because my javascript experience is rather limited. I tested it using jquery ajax call and it works in savari 15.6.

I will try to create a pull request. Are you willing to introduce jquery @aseigler? I think it is the best way to solve the problem.

Some links where I read about the problem:
https://fy.blackhats.net.au/blog/html/2020/08/12/user_gesture_is_not_detected_using_ios_touchid_with_webauthn_rs.html
https://bugs.webkit.org/show_bug.cgi?id=214722
https://bugs.webkit.org/show_bug.cgi?id=213595
https://bugs.webkit.org/show_bug.cgi?id=214444

[aseigler]

Are we specifically talking about adding jquery to the demo project? I don't think anybody has any issues with that.

[dIeGoLi]

yes, jquery to the demo project. i have it working in my project now. i will try a pull request around next tuesday.

[aseigler]

Sure, we are much less picky about changes to the demo project than we are to the library. I've been working on a larger revamp of the demo project on this branch.

[abergs]

@dIeGoLi I'm not very keen to slap jquery on as a "fixes it but not sure why"-band aid.

I would be open to change fetch to a function that uses the old xmlhttprequest method. But if safari has that kind of bug there is probably a known workaround, no?

[dIeGoLi]

@abergs It's not just "fixes but not sure why", it maybe was a little lazy not to go more into detail.
In the provided links the problem with fetch api is discussed and seems to be partly resolved. But it seems to be not the case with ReadableStream, where i suspect fetching data is included.

In my opinion the workaround is not using fetch. Fetch seems to not use XMLHttpRequest, but services workers. This async nature seems to be the root of the problem. That's why i don't see a workaround while still using fetch. I reviewed the RequestInit parameter of fetch but it provides no configuration changing the execution behaviour. jquery uses XMLHttpRequest. What i have not read and understand is the relation between promises, services workers and in general async programming in the context of javascript. There my experience is lacking.

I am quite sure using XMLHttpRequest would work as well, since it is what jquery uses. Even though i sympathise a lot with not using unnecessary libraries, in the context of the demo project i think jquery is the better alternative because my impression is everybody is using jquery instead of doing XMLHttpRequest directly. And the demo project should be written in common ways to enable people to easily read, understand and copy. But whatever of the two ways you prefer, it will work.

Edit: Well it looks like i have to read more docs instead of writing i dont have experience '^^ :
Service Workers

A service worker is run in a worker context: it therefore has no DOM access, and runs on a different thread to the main JavaScript that powers your app, so it is non-blocking. It is designed to be fully async; as a consequence, APIs such as synchronous XHR and Web Storage can't be used inside a service worker.

[abergs]

@dIeGoLi Good details. While many has moved onto fetch and left jquery, I can see the value of using jquery just to get it working. You have my blessing. A comment in the source on why we're choosing jquery would be good I think.

[dIeGoLi]

I have pretty close to the same problem working with the new Safari versions with roaming authenticators,

When i tried to use roaming authenticators in safari 15.1 safari crashed. Update to safari 15.6 has seemed to resolve that problem. Are you aware of other problems using roaming authenticators?

[dIeGoLi]

To narrow the problem a little. Login and registration does not work in safari 15.6 only with platform authenticator (tested with iPhone and fingerprint). Roaming authenticators on a MacBook on the other hand work as well with fetch.
It does not work approx. only every second time... @masteratt described that register works and login not. But it is only because it is the second attempt to interact with navigator.credentials. For example if you register two accounts right after each other, second registration will fail.

Sidenote: A similar behaviour I observed when starting the registration or login process on document load. On document load is not a user interaction, and therefore should be blocked consistently. But i observed that for example a first login attempt failed when started by document load. But then after a successful login (triggered by a button) and logout; the second login process was allowed to start with on document load. (Third not, fourth again, etc.)