Add FIDO simulator support

[karesztrk]

Hello @getify ,

I was playing with Webauthn and the webauthn-local-client library lately. I installed a FIDO key simulator on Linux using this guide: https://wiki.archlinux.org/title/WebAuthn
This is truly working on https://webauthn.io/ and https://webauthn.bin.coffee/. See the screenshots below.

However, your library does not work because of this check (provided by the platform).
I am curious if you can add support for my use case so I can develop on my workstation without investing in a Mac or Windows :)

[getify]

Thank you for highlighting your issue.

I would like to ask a clarification: are you attempting only to use webauthn-local-client project, or are you also hoping to use one of its wrapper libraries like local-data-lock or local-vault?

---

The reason I ask is: the UV (user-verification) feature is required for how local-data-lock / local-vault projects work, because they rely on being able to set the keypair seed value into the user.id field of the passkey, and that value is only returned on subsequent authentications IF AND ONLY IF the authenticator used UV. This is a limitation imposed by the spec for webauthn for security risk mitigation.

I initially put this UV check into webauthn-local-client because I knew it would be required for these other wrapper libs. But I can certainly see that perhaps I should elevate that check out of webauthn-local-client and move it up to local-data-lock instead, where it's actually necessary.

That will only help your situation if you're intending to use webauthn-local-client but NOT use local-data-lock / local-vault.

Some clarity here on your needs/intent would be helpful in prioritizing this change.

[karesztrk]

Hello @getify,

Tbh i didnt know that this library is a pillar for others. And i understand now why is that check is here. So please keep as it is. Because im just exploring usecases.
I would be happy to use Vault or Lock libs as well. So i cannot use them with my simulator? Can you point me to the part which blocks Webauthn simulators used? I dont see the exact obstacle.

If possible, can you recommend other authenticators that can be used on Linux?
Thank you.

[getify]

Chrome devtools has a built-in webauthn simulator you can use: https://developer.chrome.com/docs/devtools/webauthn (or perhaps use this plugin for firefox: https://addons.mozilla.org/en-US/firefox/addon/webdevauthn/)

As for using an actual authenticator, I'm not positive, but I think only built-in authenticators (like the touchID scanner or the FaceID camera) that actually come IN THE DEVICE will act as "user verification" authenticators for the operating system. I don't have experience with linux as a desktop OS (I only use it CLI via SSH for remotely managing web servers), but I do think it's definitely a bit more challenging to get a device and linux OS setup that properly support the authenticators. It seems like linux is always a bit more "you have to figure it out yourself" on these sorts of things. Shrugs.

---

As I mentioned, the UV part is required if you want to use the Local Data Lock and/or Local Vault libraries (which wrap this one). They are used to perform data encryption (and secure storage), totally on the client, based on the passkeys that this library creates/manages. Those techniques are relevant mostly for local-first software development (which is the point of these libraries).

So you just have to decide whether you want to go that local-first route and do data encryption/storage in the client based on passkeys. If so, yes, have a look at local-data-lock and local-vault.

However, it's possible to use just this library (webauthn-local-client) if you are not doing encryption based on the passkeys, but only doing authentication (aka "login"). In that case, it would be helpful if this library removed the check for UV, since this library doesn't actually require that, and it would make it so this library can be used with a broader array of authenticator devices, such as the FIDO USB sticks and other things like that. It would also make it work with separate virtual authenticators.

So I will plan to make that change, regardless, because it's the proper design separation, to keep this library as broadly useful as possible.