Unify registration and authentication

[yacovbarboi1]

Hey.

First of all, thanks for the great library, it works as charm :)

I thought of creating 1 button for both registration and authentication to reduce user friction.

I wonder if its even valid (security-wise)?

If so, adding a support for that kind of flow can be great.

Thanks!

[MasterKale]

I wonder if its even valid (security-wise)?

I think it can be a valid flow, in fact I did something like that with my https://dontneeda.pw/access demo site from back before I made SimpleWebAuthn (in fact a lot of code in the library originated from this project). There's a single form you enter an email address into, and based on whether you've registered before the magic link that gets sent to your email address either triggers registration or authentication when you click on it.

I can't say I've seen too many other sites do that, but I do think it's at least feasible. Your job as an RP would be to pull that off in a way that doesn't confuse both new users and returning users who are used having separate "Sign Up" and "Log In" forms to fill out.

If so, adding a support for that kind of flow can be great.

The UI logic that would power a flow like would definitely not be handled by this library. Supporting two flows from a simple one-button form can be easily accomplished with the four primary methods of @simplewebauthn/server, however you'd need to write the logic to know when to call them because, at the end of the day, WebAuthn still requires taking four steps on the server:

1. Generate registration options
2. Verify registration response
3. Generate authentication options
4. Verify authentication response

There are myriad NodeJS server frameworks in which these methods can be called, and nevermind all the different ways to architect relying parties, so I don't think it'd be appropriate trying to incorporate new functionality SimpleWebAuthn targeting any one combination of things.

Might you have an idea for how I might add support for a single-button form?

[strefethen]

First, kudos for putting all of this together and sharing it on the Internet, much appreciated. The directions for setting up webauthn on a custom https domain are just perfect, well done.

Back to this thread...

Curious if have you gotten much feedback on your dontneeda.pw implementation? I tried testing a fully login/out/in cycle on dontneeda.pw and upon clicking the second link email I get the message:

Hmm, something went wrong. Ask an admin to check it out... (Reason: Device's counter 0 isn't greater than 0!)

Ignoring the error your example implementation feels probably about a smooth as it seems one could make webauthn ATM though having to use a magical link every time seems pretty painful. It requires users to leave the website, go to their inbox, risk getting distracted and never return. My suspicion is it would lead to pretty significant drop-off in session retention.

Also, with webauthn it seems like the user data we need to collect HAS to be either email or phone # giving us the option to reach the user and actually validate their account.

While this work allow users to forego a password it I'm struggling to see this as simplifying the authn flow and thus doesn't feel very much like progress.

As I google around I find many similar threads regarding webauthn being progress towards getting rid of passwords but the UX is lacking to the point where we don't see it used much.

Curious if I'm perhaps not understanding something? I'm feeling like I just need to implement basic email/password auth and forego webauthn at least for now.

[MasterKale]

dontneeda.pw is definitely not an exemplar of ideal WebAuthn deployment. It's over two years old now and was only ever me playing around with WebAuthn to get a feel for it. I learn when I have something to build and a WebAuthn-powered OIDC provider was the perfect project to tackle (well, in hindsight maybe not since OAuth is such a huge PITA 😂). The magic links were my naive attempt at offering a truly passwordless SSO experience and yeah, I agree, thinking as an end user they have terrible UX.

Also, with webauthn it seems like the user data we need to collect HAS to be either email or phone # giving us the option to reach the user and actually validate their account.

There's nothing preventing you from establishing completely arbitrary usernames and IDs for your users, if you so chose. Nothing about the use of WebAuthn requires users to divulge anything resembling PII. It's the RP's choice to decide that. The argument for requesting phone number or email is primarily to prevent bot accounts from signing up for your service. If your requirements don't care about that then you can simply let users specify a username instead to create an account, at which point you a randomized user ID to make things even less user-identifying.

While this work allow users to forego a password it I'm struggling to see this as simplifying the authn flow and thus doesn't feel very much like progress.

Have you seen the demo that Google and Microsoft presented a few months back? I think it does a great job of showing off the registration and authentication happy paths that are now possible with WebAuthn/passkeys:

https://www.youtube.com/watch?v=SWocv4BhCNg

When done properly, WebAuthn-based authentications can happen so quickly that users almost think nothing happened. And in fact many users express a seemingly contradictory reaction, that something so quick and thoughtless "could be any better than a password + 2FA." You gotta bake in delays to the auth experience so that users aren't scared away from using WebAuthn 😅

[strefethen]

dontneeda.pw is definitely not an exemplar of ideal WebAuthn deployment. It's over two years old now and was only ever me playing around with WebAuthn to get a feel for it. I learn when I have something to build and a WebAuthn-powered OIDC provider was the perfect project to tackle (well, in hindsight maybe not since OAuth is such a huge PITA 😂). The magic links were my naive attempt at offering a truly passwordless SSO experience and yeah, I agree, thinking as an end user they have terrible UX.

I don't think it was quite as far off as you make it sound, it was good POC. :)

Also, with webauthn it seems like the user data we need to collect HAS to be either email or phone # giving us the option to reach the user and actually validate their account.

There's nothing preventing you from establishing completely arbitrary usernames and IDs for your users, if you so chose. Nothing about the use of WebAuthn requires users to divulge anything resembling PII. It's the RP's choice to decide that. The argument for requesting phone number or email is primarily to prevent bot accounts from signing up for your service. If your requirements don't care about that then you can simply let users specify a username instead to create an account, at which point you a randomized user ID to make things even less user-identifying.

To me, this seems mandatory as I can't really imagine anyone wanting to so easily allow bot sign-ups thus making PII mandatory, at least to me.

While this work allow users to forego a password it I'm struggling to see this as simplifying the authn flow and thus doesn't feel very much like progress.

Have you seen the demo that Google and Microsoft presented a few months back? I think it does a great job of showing off the registration and authentication happy paths that are now possible with WebAuthn/passkeys:

I hadn't seen the video so thanks for the link. I watched it and the user in the example starts with a username/pwd based account and "upgrades" it to webauthn. They don't cover the initial username/pwd account creation which is really what I was hoping was the piece that could be replaced, but alas not yet.