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

311–320 of 347 posts

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

#311

Post by mattowen_uk »

greggman3 wrote: post #281
movedx wrote: post #245

Earlier quoted context omitted.

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

I don't get this comment. I've been in plenty of situations where I need something now . Doctors office, DMV, tax office, etc... It's not about being impatient. It's about knowing that it should be instant and it not being instant. If you turned on your water faucet, shower, or flushed your toilet and water didn't run for 45 minutes most people would be shocked.

> Flush Button Push Detected

> Contacting Toilet Cloud Server...

> 503 Service Unavailable

> Alert User: "Water Unavailable, Please try Later."

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

#312

Post by nojs »

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 so annoying as a user! It’s like you’re making me do a password reset every time I want to log in, and I have to sit there and wait until the email arrives.

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

#313

Post by vagrantJin »

mattowen_uk wrote: post #311
greggman3 wrote: post #281

Earlier quoted context omitted.

I don't get this comment. I've been in plenty of situations where I need something now . Doctors office, DMV, tax office, etc... It's not about being impatient. It's about knowing that it should be instant and it not being instant. If you turned on your water faucet, shower, or flushed your toilet and water didn't run for 45 minutes most people would be shocked.

> Flush Button Push Detected > Contacting Toilet Cloud Server... > 503 Service Unavailable > Alert User: "Water Unavailable, Please try Later."

In a strange sense, I feel this joke is not too far from reality.

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

#314

Post by dmak »

pchm wrote: post #293
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…

Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic. But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are…

especially on corporate vpn

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

#315

Post by pelasaco »

kevin_thibedeau wrote: post #283
RandallBrown wrote: post #263

Earlier quoted context omitted.

Is there a technical detail of email that I don't know about that makes it less low-latency than a text message? Email or text would work the same for this auth scheme anyway.

SMS can be delivered days late. It isn't any better than email.

And as I discovered in my own service: If the SMS aren't being sent - or the clients aren't getting them - there are so many parts involved that's really hard to pinpoint the problem and get an ETA for the solution..

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

#317

Post by pelasaco »

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…

> password handling workflows are now the email provider's problem.

if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)

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

#318

Post by anonymoushn »

advaitruia wrote: post #309
anonymoushn wrote: post #264

I guess not, since it's for nodejs only. I would use it if it had a frontend component and instructions for implementing the backend component.

We do have a frontend component as well as instructions for implementing the backend. Currently we support login for nodejs and session management is supported for several frameworks. We will be adding login support in the near future

It looks like step 1 of integrating supertokens is writing a driver, and if I would like to do this the docs invite me to chat about it on Discord.

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

#319

Post by wdb »

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…

Yeah, I am not a fan of magic tokens / login by email address either. It's a pain to need to message yourself with a token url and then the messenger app does previews which renders the token invalid and then you need to save a text file with the url in it, send it open it, copy paste the url into the browser. Just to login.

Sure, you could say, why don't setup your email on your devices but I shouldn't need to do that. Just to use your website. These magic links are just not user friendly

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

#320

Post by jmartrican »

corytheboyd wrote: post #69

I know most people are not like this, but I don’t mind setting up auth “over and over” It’s always a chance to read about what’s changed in the technologies/ideas you usually lean on for it. Apply that simplification that you wish you could have for your already launched application. Maybe you have a need to make your auth slightly more proprietary. If you churn out applications all the time yeah I get why this could…

I have my own auth solution that I carry with me. If my employer or client has a better auth solution, great I use their's, else I'll give them mine. Which is basically a working implementation of Spring OAuth. And I keep it updated as Spring updates it. I feel that knowing one solution well enough that you can implement any reasonable use case is better than constantly learning and dealing with the shortcomings of other solutions.

When you learn Spring OAuth well enough you can basically bend it to your will. It provides enough hooks and interceptors to do whatever you want. But it has a steep learning curve.

Post reply on HN