Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sick of spending time on Auth, we built an open source 'Stripe for Auth'

news.ycombinator.com

Post reply on HN
Print view View original

221–230 of 347 posts

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#221

Post by mekster »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

This is just being lazy over customer experience.

I don't like having have to click the link, trash the email and close the previous login tab.

> I can use manual processes to verify the person

What does this mean?

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#222

Post by cstejerean »

OJFord wrote: post #215
movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option). And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect. It's especially annoying when setting up a new device - oh right yes, obviously I need…

For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse.

But for certain things that I need to do say once a year (let’s say renew some kind of registration or insurance) I wouldn’t mind it. Because chances are I already do this because I forgot to save the password in my password manager last time and now I need to do a reset password flow anyway.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#223

Post by protoduction »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API.

[0]: https://magiclogin.net

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#225

Post by fakedang »

advaitruia wrote: post #182
fakedang wrote: post #177

Earlier quoted context omitted.

> We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail. Just curious about this model, but if you keep only the essential features on the developer plan (good for startups but not much above that), while the enterprise plan requires more c…

Sorry, I am not sure I completely understand. When you say that we may not be able to provide because it would be expensive - do you mean it would be expensive for us to build or for startups to buy? What exactly would the catch 22 situation be?

What Aeolun said. Basically if you don't provide those features that enterprise wants from the get-go, and count on the enterprise plan to fund the development of those features, doesn't that land you in a catch 22?

Not that I'm criticizing your model, but I'm just genuinely curious. I would switch to using this in a heartbeat if it doesn't end up too complicated. And lots of thanks to other HNers for downvoting me when I asked an honest question on SaaS pricing.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#227

Post by teleforce »

protoduction wrote: post #223
movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API. [0]: https://magiclogin.net

This my friend is utterly brilliant!

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#228

Post by RandallBrown »

OJFord wrote: post #215
movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option). And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect. It's especially annoying when setting up a new device - oh right yes, obviously I need…

I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on.

There's something very appealing about not having a password that I need to store anywhere for that service too.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#229

Post by miguelmota »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

Username + password is nice when you have a password manager that auto-inserts the credentials for you into the form. The 1Password extension and browsers with builtin password managers do this. All I have to do is click login and I’m in. The magic link flow is more of an inconvenience in this regard because it involves jumping around apps.

Re: Sick of spending time on Auth, we built an open source 'Stripe for Auth'

#230

Post by artificialLimbs »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

As an alternative...I wonder if there could be a auth process where the user creates a writeable 'space' for a site/app with a one time key in their password manager, gives the site/app the key, then the site uploads new login credentials directly into the password manager.
Post reply on HN