Idea: Add new helper methods for MFA, PWL, and Usernameless registration and authentication

SimpleWebAuthn already makes interacting with the WebAuthn library fairly painless, but can I take things one step further? The thought occurred to me that I might be able to offer a higher-level abstraction to the registration and authentication options generation and response verification methods. These abstractions would set combinations of options appropriate for use of WebAuthn for MFA, Passwordless, and Usernameless “modes”, with minimal arguments to specify things like allowCredentials:

Registration

• getMFARegistrationOptions()

• getPWLRegistrationOptions()

• getUNLRegistrationOptions() (UNL -> “Usernameless”, you heard it here first! 😅)

• verifyMFARegistrationResponse()

• verifyPWLRegistrationResponse()

• verifyUNLRegistrationResponse()

Authentication

• getMFAAuthenticationOptions()

• getPWLAuthenticationOptions()

• getUNLAuthenticationOptions()

• verifyMFAAuthenticationResponse()

• verifyPWLAuthenticationResponse()

• verifyUNLAuthenticationResponse()

Or maybe a new, optional mode argument on the existing methods that you specify as "mfa" | "pwl" | "unl"? That might actually be cleaner 🤔

In any case the idea is, there are certain options you must set if you want to, for example, leverage WebAuthn for Passwordless login. Without digging into the docs, though, you might not think to set them. I think there’s a chance here to help devs even further by offering a quick and easy way to generate appropriate options and verify responses that will help ensure secure authentication for all use cases.

[MaKleSoft]

Oh, and I vote for the mode argument instead of a ton of different functions. Just my preference though.

[MaKleSoft]

That sounds like a great idea! I think one of the main hurdles for many devs trying to adopt WebAuthn is understanding all the different use cases and how to implement them. Heck, I still haven’t fully grasped how “passwordless” or “usernameless” are supposed to work in practice. I think descriptive APIs like the ones you’re suggesting are a great way to guide developers towards the solution they’re looking for and help avoiding many pitfalls and frustrations when adopting a new technology.