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

181–190 of 347 posts

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

#181

Post by advaitruia »

desireco42 wrote: post #134

This is really cool. Thanks for making it. Thinking on how I would use it, I appreciate free tier, but I think once things get more involved, I might actually do self hosting, which leaves you without income. I would see about that, otherwise it is cool. If you can't make money, then just when we start using it, you might decide this is not worth pursuing and it wouldn't be good for everyone. Wish you the best.

Thank you for the encouragement, we appreciate it!

We are happy with developers and early stage startups using SuperTokens for free. Our plan is to monetize feature that are required by enterprises. We have a philosophy section in the pricing page that explains this is more details

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

#182

Post by advaitruia »

fakedang wrote: post #177
advaitruia wrote: post #137

Earlier quoted context omitted.

Thats incredibly insightful because that is exactly our plan :) 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

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

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

#183

Post by mooreds »

rishabhpoddar wrote: post #105
mooreds wrote: post #101

Interesting. From reading the website briefly and the announcement above, this seems like a "super library". If there's an auth spectrum, from: roll your own -> use a language specific library -> use a full featured solution like Auth0, Firebase or FusionAuth it seems like SuperTokens is in between the library and the full featured solution. I guess I'd ask, if I don't want a full featured solution (the use case you'…

Thanks for the comment and disclosure :) We do intend to be a full featured solution. Though, since we are relatively new, we only provide email and password. That being said, our approach is modular in nature so that users get only what they want.

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

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

#185

Post by iamlolz »

rishabhpoddar wrote: post #68
afandian wrote: post #54

Earlier quoted context omitted.

I came here to question exactly that. > Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon That's a very very odd combination.

We have SDKs for other backend frameworks as well (like golang, laravel...). But those only have a session feature, and not login. Hope this provides some clarification.

Do you have a ETA for flask login support? I literally just rolled my own but I'll want to switch it over at some point.

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

#186

Post by darkhorn »

beachy wrote: post #66
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.

I cannot imagine building auth into a system now without using Keycloak. It's a comprehensive platform for sure, which makes for some pretty intense concepts and documentation. But once you lay your hands on a suitable tutorial it's dead easy to get running, and you'll never find yourself stuck when some PHB asks you about your password rotation policies, 2 factor auth, SAML, SSO etc. etc. Keycloak does everything yo…

I think Keycloak is very complicated. Lots of things to learn. It is like a space shuttle with lots of settings.

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

#187

Post by Aeolun »

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?

If I need to pay to access the enterprise features (just like with Auth0 or Cognito), why wouldn’t I just use those?

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

#188

Post by movedx »

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 address in the database. This has never happened.

EDIT: "fault" => "problem"

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

#189

Post by eloff »

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 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 requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.

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

#190

Post by cdnsteve »

From an SDK approach you might want to start with a generic language library/sdk rather than a specific framework. In Python for example, I see a Flask implementation (cool) but wishing there was one for Django. You will get more miles out of a generic SDK per language, than can be used within framework specific implementations longer term. Less to support and less overhead to test.
Post reply on HN