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

231–240 of 347 posts

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

#231

Post by scrollaway »

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

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

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

#232

Post by nl »

fakedang wrote: post #225
advaitruia wrote: post #182

Earlier quoted context omitted.

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

As a (potential) consumer of this type of service I can attest that this is fine with me.

I had a SAAS for a while where insisted on SAML-based authentication for a full roll out. However, they were happy to do a (cheaper) paid trial without it.

A service like SuperTokens works well here because its costs and complexity scale with my requirements. Unlike Congnito it is literally free and completely under my control at the start, but there is a reasonable forward migration path that doesn't involve a complete auth rewrite going forward.

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

#233

Post by ed25519FUUU »

artificialLimbs wrote: post #230
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.

You mean like FIDO?

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

#234

Post by mooreds »

fakedang wrote: post #225
advaitruia wrote: post #182

Earlier quoted context omitted.

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

FusionAuth (the company for which I work) have a similar model with a free (though, in our case, not open source) community edition for developer reach and to lower the barrier to entry.

Then support and enterprise features are paid for by the enterprise. If you can find the right levers, it works.

This has been a common business model. Redhat did it, Hashicorp does it, Rancher I believe as well. The entire SSO Tax group of companies ( https://sso.tax/ ) have variable pricing because companies will pay for features like SSO that devs won't.

The question, especially with an open core model, is what happens if the cloud providers do to you what they did to mongo or elastic. I found this article interesting: https://joemorrison.medium.com/death-of-an-open-source-busin...

I think the jury isn't out on opencore as a business model and auth is certainly the right kind of horizontal platform play. And there's certainly room for all kinds of business models in auth, as it's a gigantic market.

Disclosure: I work for FusionAuth.

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

#235

Post by cortesoft »

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…

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

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

#237

Post by mooreds »

AsyncAwait wrote: post #193
mooreds wrote: post #183

Earlier quoted context omitted.

So if you are aiming to be full featured, the modularity plus open source is your differentiator? What are you going to do if AWS/GCP/Azure decides to offer a managed services version of your software? (I know, I know, that'd be a a great problem to have.)

AWS etc. already offer these services so the risk is low. I dislike the recent trend of companies changing licenses from a formerly FLOSS solution to "source available". It prevents little in practice and makes it so that your original differentiator i.e. open source is no longer true.

> AWS etc. already offer these services so the risk is low.

I'm not sure about that. AWS had a NoSQL database, but replicated mongodb.

Anyway, I think that the risk doesn't occur until and unless supertokens hits a home run. I mean, if you're big enough for a hypercloud provider to copy, that means you've been pretty darn successful in distribution of your product.

But the risk is there.

As for the relicensing, I have sympathy for both viewpoints. I posted this in a different comment, but this medium article does a good job of talking about both sides of the issue: https://joemorrison.medium.com/death-of-an-open-source-busin...

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

#238

Post by eloff »

advaitruia wrote: post #13
Scotrix wrote: post #8

We’re using Keycloak.org which is a great product, easy to use, a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect from modern user authentication and management system. You should check that out, user auth is indeed a solved problem.

Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak: We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity. We provide far more flexibility and options on the frontend as well KeyCloak is a small part of the Redhat (and even les…

I'm also curious about multi-tenancy.

Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?

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

#239

Post by movedx »

codemac wrote: post #216
movedx wrote: post #213

Earlier quoted context omitted.

You're not my target audience and you have an esoteric approach to privacy.

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 happy to lose as (paying) users/customers.

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

#240

Post by dragonwriter »

RandallBrown wrote: post #228
OJFord wrote: 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…

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.

> 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

Post reply on HN