Show HN: Passwordless Login as a Service | Hacker News Reader

Show HN: Passwordless Login as a Service

gopasswordless.dev

8 pointsjblox9 comments

I like the idea of the product. (I work for FusionAuth and we have a passkey solution, but the more folks who offer this the better, IMO.)

I tried to sit up for the app on with chrome on my android device. It looks like it captured the passkey but didn't send the verification email (or maybe it hasn't landed yet). When I try to login I see "user not verified" and can't proceed further.

When I try to sign up but my email address was already registered, I get the unfriendly message "failed to fetch" :)

I assume you are using the library for your app. If so, would be awesome to get these rough edges fixed.

I also think that it would benefit from a simple example app, even an express one. That would let folks play with it easily.

Thanks for the feedback :)

Ah ok, it's using Sendgrid (free tier) for the emails so perhaps that's impacting deliverability - I have found in the past the shared IPs can be hit and miss. I'll look at switching to a paid service and make sure there's a way to have the email resent if it doesn't deliver.

Sure, I'll look into cleaning up the error messages and providing a demo app next.

Awesome!

This functionality is how stytch and passage both started.

One raised a bajillion dollars and is continuing to push identity forward and the other was acquired by 1password, so this project could have some legs.

Good luck!

Does this work on all devices/browser combinations? (well not all strictly, but lets consider the majority users)

There are two factors to consider here, and those are "Will it work?" and "Will the UX be good?".

Will it work?

What we need to look for here is support for Webauthn, we can see here that all of the popular browsers support Webauthn - https://caniuse.com/?search=webauthn across desktop, iOS and Android, covering ~96% of all users.

Will the UX be good?

This is where we start to look at support for things like biometrics and generally, we'd prefer that user's passkeys are secured on their devices using biometrics rather than a PIN. In this area, the support is good across modern mobile devices (fingerprint and/or face id) and many newer desktop devices (e.g touchid). Probably the most obvious limitation here is a desktop device with no support for biometrics, however, Webauthn has a neat solution here where a user can link up this device with their smartphone using either bluetooth or by scanning a QR code - this then allows the user to login using a desktop device with a passkey secured on their mobile device.

Most of the popular password managers now also support passkeys, so that's another workaround that works well in many cases.

What do you store then if there's no password?

It uses Passkeys to secure a user's account (https://fidoalliance.org/passkeys/).

Passkeys use public key cryptography, so in this case we have a private key that remains securely on the user's device, and a public key that's stored on the server. Most modern devices are able to secure the passkey using biometrics, but users can also choose to use a password managed that supports passkeys.

Seems pretty cool, what about user data then? How do you assign a key to a user?

The only user data required right now is either an email or mobile number, which gets verified using a code that gets sent to the email or mobile number used. The working assumption is that any consumer of this would use it alongside their own database, so there's probably no need to store anything other than the email/mobile (or username in WebAuthn terminology, this doesn't technically need to be an email or mobile, but I chose to do this so I could add a verification step to help prevent abuse of the system).

The passkey is created by the user's device and then the public key part of it is sent to the server during user registration.

Reply on news.ycombinator.com