webauthn | node.js webauthn framework | Authentication library

Your locators are correct, but the Creds input boxes are in an iframe.

So first switch to an iframe with the below XPath:

The Web Authentication API is disabled by default in cross-origin iframes. To override this default policy and indicate that a cross-origin iframe is allowed to invoke the Web Authentication API's [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method, specify the allow attribute on the iframe element and include the publickey-credentials-get feature-identifier token in the allow attribute’s value.

https://www.w3.org/TR/webauthn-2/#sctn-iframe-guidance

This flow works on all of my apple devices, however, on Android the 'fmt' of the credentials is 'android-saftynet' which doesn't seem to support userHandles.

Just to clarify, the format of the attestation statement has no bearing on an authenticator's ability to return a userHandle from navigator.credentials.get(). According to the spec it's basically up to the authenticator whether it wants to return userHandle or not.

Are there any formats I can force on Android that I can save userHandles with?

WebAuthn doesn't offer any way for an RP (Relying Party, i.e. your server) to require a specific attestation station format, so you either have to support them all (for which I'd highly encourage you use an existing library) or pick and choose and reject registration of credentials with statements you don't want to support.

Or another way to store information with the publicKeyCredential to allow me to support the usernameless webauthn flow?

I'll correct this if I'm wrong but I don't think you need userHandle to accomplish usernameless. You should be able to take the credential ID you get back from navigator.credentials.get() and match it first to your list of registered credentials, and then pull the corresponding user ID from your own internal record of which credentials belong to which user.

All that to say that FIDO2 support on Android is a little spotty. Last I checked discoverable credentials are basically unsupported on the platform which means usernameless support on Android devices is pretty much out of the question for now.

No. Typescript types will be emitted during the compilation phase.

Your options are:

1. Use JSON-Schema (Ajv) to validat the input of incoming http json requests: https://github.com/ajv-validator/ajv
2. Use Swagger (Almost the same as (1)).
3. Use a validator which works with your framework.
4. I found this project which tries to create runtime asserts from typescript types: https://github.com/skunkteam/types. But I never used it my self.
5. https://github.com/nanoporetech/ts-runtime-typecheck - Same as (4) but never used it as well.

After doing some more testing with Edge (and discovering the "thisisunsafe" trick), I've discovered that WebAuthn isn't a big fan of ports. So, it didn't like: "id":"subdomain.domain.tld:port".

Replacing $_SERVER['SERVER_NAME'] where $_SERVER['HTTP_HOST'] when initializing the $WebAuthn Variable fixed the issue.

Basically navigator.credentials.create() doesn't accept ids with ports.

Is this a known limitation of WebAuthn itself?

This has nothing to do with WebAuthn the API and everything to do with macOS. To date macOS is the one platform that requires WebAuthn credential management to take into account which browser the credential was registered in.

...how are devs getting around this issue?

One way to address this is to store the user's OS and browser at registration (via traditional user agent, the newer navigator.userAgentData, etc...) with the new credential. Then, at auth, grab the user's current OS and browser info and use it to filter credentials to include in allowCredentials that you'll pass to navigator.credentials.get(). If a credential was registered on macOS then filter by browser too; on other platforms you can simply filter by OS.

If allowCredentials is empty on macOS after filtering the user's credentials (i.e. because the user has a single credential that was registered in Safari but the user is currently using Chrome) you need to handle that and prompt the user to log in some other way before prompting them to register Touch ID in Chrome.

This is incredibly annoying to deal with, but it's the reality of WebAuthn on macOS. Fingers crossed Apple's passkeys (now in Tech Preview on Monterey) will offer a similar experience to iOS' OS-level credential store once it rolls out more widely...

Why don't you use the Web Crypto API?

This API is designed for cypher operations on client side and is suitable for your use case (client side encryption). It is supported by all recent browsers.

Note that the main concern you may have is that this API does not supports hardware devices (smartcards, security tokens...).

However, your Yubikey is certainly capable of generating a secured static password you can use as a master key you will derive to encrypt/decrypt your data.

Everything about the options you pass to navigator.credentials.get() looks correct, including how you're specifying the "appid" extension. I believe the issue is that you're double-encoding your U2F credential's credential ID. Try passing the original "keyHandle" in the options instead (you can use it as-is because it's already compatible with base64url encoding):

So lets think about authentication in general. Authentication is a feature of a specific service, that is implemented in a specific way by the service. The user experience may be similar between Google and Facebook, but the flows, API, password hashing are unique to each provider.

To figure out if you can login to a website with a password, you need to go to a website, and see if it has login form for example.

Same way with WebAuthn. This is not some in-browser magic. If you want to see if you can use WebAuthn with a website, you need to try to login to a website and see if it is utilising WebAuthn API during the login.

WebAuthn API simply provides ability to generate credential, and get assertion(proof) for the credential. You may use this information to authentication user. How you do it exactly, and the process of performing validation is different for each service.

So in conclusion:

WebAuthn API does not have functionality to figure out if user is logged it, because this is not what WebAuthn API is for.

If you are interested in learning more about WebAuthn:

We have a cool guide: https://webauthn.guide/

A collection of useful resources: https://github.com/herrjemand/awesome-webauthn

And a deep dive into WebAuthn API: https://medium.com/webauthnworks/introduction-to-webauthn-api-5fd1fb46c285