Live data from Hacker News

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

news.ycombinator.com

241–250 of 347 posts

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

#241

Earlier quoted context omitted.

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

isn't that the same as https://magic.link ?

The base idea is the same yes, but the pricing and featureset are different.

Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing).

tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.

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

#242
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…

So there is no way to login on any device that isn’t your own?

You can login to any device on which you can login to your email. Most people can login to their from anywhere, on any device, via a browser.

I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.

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

#243
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?

> This is just being lazy over customer experience.

Can you expand on this? My users actually voted for this feature.

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

#244
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…

So there is no way to login on any device that isn’t your own?

You can extend this idea to include a one time code in the email that can be manually typed on another device.

Including a QR code of the link also helps.

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

#245
post #215

Earlier quoted context omitted.

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 n…

> 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.

It's incredible to me how impatient we've become as a society.

As everything is given to us faster and faster, with less and less financial cost, the more we demand this of everything going forward. Anything that comes shy of this demand by mere minutes is shunned as unacceptable.

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

#246
Hey Advait! Glad to see your work here man :) Will be watching the project closely over the next year. Having recently re-built authn + authz using Cognito (we evaluated Auth0 and building it ourselves as well) I can confidently agree that doing auth right is hard and complex. Especially once you get into social providers, keeping identities synced, MFA, etc. Excited to see where the project lands!

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

#248
post #189
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 had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email. Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where…

> We changed how our sessions work to get around it

In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with.

The only real quibble here might be that duplicate requests cost you unnecessary transit.

Post reply on HN