Live data from Hacker News

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

news.ycombinator.com

281–290 of 347 posts

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

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

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

#282
post #242

Earlier quoted context omitted.

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.

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

So basically this is not a solution for 99% of all services. Thanks for clarifying

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

#283

Earlier quoted context omitted.

> I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on. MFA usually uses channels that are intended to be relative low latency (or that don't require realtime out-of-band transmission, like TOTP). Email, OTOH, isn't generally reliably low-latency

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.

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

#284
post #243

Earlier quoted context omitted.

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.

I explained it right below. I see some might like it that way for security reasons.

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

#285
post #239

Earlier quoted context omitted.

Most of my friends/family who use work laptops/computer do the same thing - they log in via a private browser so they don't get work credentials mixed with personal credentials. I think firefox containers are a great way to handle this, and a lot of folks don't know how to use chrome or other browsers with multiple identities. Maybe look past that this user is doing it for privacy.

I believe the inconveniences are worth it when your users aren't power users or even that proficient with a computer; and your users select passwords like "snoopy55" or "ilovejesus". If the aim of the game is to produce a non-critical system that's accessed rarely, and your users need protecting against themselves, then this "magic token" approach works fine. I can't please everyone, and those who I can't please I'm…

Those people are also far more likely to have their email breached, along with the logins you provided on a silver platter. Also they can't log in to your site when the third party email provider goes down. I understand why you prefer this approach for your site, but can not recommend having such strong third party dependencies.

Also, personally, not a fan of losing access because e.g: Google disabled my account. I avoid google and fb login like the plague. (I am slowly looking to migrate off/away)

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

#286
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 did the exact same for a recent project, a small internal tool for geo data collection in cities. It comes with tradeoffs as others have mentioned but it’s pretty great for getting something going quickly with a small number of users. All you need is mailgun or similar key and you’re off.

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

#287

Simple, JWT, pick one. Really don't understand the obsession with JWT, especially if you don't need SSO. Only real advantage of JWT, vs the tried and true random session_id+database approach, is that you don't need the DB. What useful web application needs auth, and doesn't already have a DB?

This is a debatable topic. We wrote a blog post about this as well: https://supertokens.io/blog/are-you-using-jwts-for-user-sess...

The benchmark in that article comparing JWT to opaque session id's doesn't mention what database setup is used or what JWT signing scheme is used.

Presumably it's just using a HMAC, I think if it used RSA or an asymmetric signing scheme, the performance would look much different.

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

#288

“We couldn’t afford to pay It took too long to understand the documentation of alternate service providers” These don’t seem like good reasons and would be enough to make me not want to use this until it already has a lot more real-world usage from others first.

Thank you for your candid feedback. Those reasons were also echoed in our user research as we were dedicating ourselves to the project. Could you please share why you think those arent good enough reasons? Ofcourse, social proof is important regardless. SuperTokens is being used in the real world, in production. Would you like to see more people using it or some recognizable entreprise brand names?

It's not the technique that makes me wary - it's that the way it reads is that you've built this because you found the documentation for existing solutions to be too complex which is a massive red flag with regards to anything security related.

Essentially it sounds like "doing security is hard so we did something simpler and ignored the complicated parts we couldn't understand".

As you've explained it above that's clearly not what you meant at all so maybe edit the website to call out a bit more clearly what your reasons are for building this and what other people's complaints are about existing systems? (Maybe in one of those side-by-side feature matrices showing the benefits of your implementation?)

Will definitely check this out when I have some time though!

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

#289
This is amazing! Wish you a lot of success. Will there be a way to submit feature requests, upvoting and you working on the most requested?

Would be great if you would add user management, including profile photos and custom fields in the future. And SMS login.

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

#290
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 don't mind this. 7/10 times I'm doing the password reset thing already when I visit a site I don't use much but know I have an account with, so this just cuts to the chase

I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link

Post reply on HN