(example): not friendly UX when trying to sign in before registering

[SimoMay]

Clicking on Sign in with passkey before creating a user or registering the device causes confusion.

The example client will get the publicKey.challenge and initiate the process before requesting an email and checking if we do have user/device registered first.

Before a user is created:

After a user is created:

Solution:
BestBuy flow seems reasonable, you can do email login flow, or you click on Sign in with WebAuthn, it routes to a form to fill in the email first, checks that it's possible, respond with an error that it's not possible till it's setup first.

[bjoern-m]

Hi @SimoMay,

Thank you for your feedback. I have looked into it and guess one problem is, that during the WebAuthn finalization several things can go wrong and the API uses different status codes, but only one status code translates into the "Invalid WebAuthn credentials" error. Not sure what in your case triggered the "Technical error" but I see space for improvement here. Will create a PR shortly, so that hopefully in both cases described, the same error occurs.

The other question is whether we can improve the login flow. I think theoretically we could determine from the credential assertion response whether the user exists and display a registration page with an email input. But the assumption that a user wants to register a new account in this case might be wrong. And what are the real cases the error gets displayed?

When the browser noticed there is no WebAuthn credential for the current origin, the browser displays an error message. So the sign in fails before there is a credential assertion. And when you've chosen a credential that has maybe been removed from the database, it's reasonable you get an "Invalid WebAuthn credential error". Another thing is that on Apple devices, for example, WebAuthn credentials cannot be used across browsers, and a credential registered on a Windows device will not work on an Apple device and vice versa. So the user account is in place, but on the current device there is no WebAuthn credential registered yet. Then the way to log in is to fill in the email input and after entering the passcode or password
the UI presents the Webauthn credential registration page so the WebAuthn sign in will work the next time on the current device/browser.

Also notice discoverable credentials are used, i.e. "Sign in with passkey" does not involve the input of an email address. By clicking the button, the browser displays a UI where a credential, stored on the authenticator, can be selected. So no identifier first approach regarding the "Sign in with passkey" button.

Since the WebAuthn Conditional UI feature is announced, please also take into account that the email input will have the ability of the "Sign in with passkey" button. It will be possible to trigger WebAuthn via the autofill menu of the email input, where you can select WebAuthn credentials besides the common email/password logins. This will hopefully improve the UX a lot.

Anyway, it's also true that there have already been discussions at Hanko about splitting the combined login/registration page into separate pages or web components for login and registration, which would be close to your suggestion.

This is all I can tell you about it at the moment. Let me know if I got you right at all and please share your thoughts.

Kind regards

[SimoMay]

Great to see! I believe you guys already thought about all this and have solutions to make it better.

[bjoern-m]

Alright, I'll merge the PR and close the ticket for now. I assume that we can benefit from the conditional UI feature end of September. Stay tuned!