Live data from Hacker News

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

news.ycombinator.com

81–90 of 347 posts

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

#81

Earlier quoted context omitted.

Thanks for the valuable suggestions! Email verification is next on our list of features. We plan on providing an "active" method which requires you to verify the email to sign up, and one "passive" method which reminds you to verify the email from time to time post sign up (similar to many social networking sites).

Do you have a uservoice page or issues on github where we could vote in support of a feature like this? I know "me too" comments might not be the most helpful but... this sounds like the only blocker for me too!

We don't have that unfortunately. However, a quick hack is to upvote an issue related to the feature you like the most, or create an issue in case it does not exist.

But thanks for the idea! It's a great one.. will have a look at it.

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

#82

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…

Ofcourse, everyone has their own preference. Thats an interesting perspective as well. My only counter to that would be that its time consuming to roll your own auth for a complex or large scale app. It starts off easy but soon you have to make significant investments in various aspects of auth. That isnt true for all apps ofcourse. Definitely good to keep learning though!

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

#83

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.

I was mostly confused that you would write something in Java that doesn't target Java.

I'm writing stuff in Java (and Kotlin and Clojure) and, even though it looks cool, won't look too closely unless it supports Java.

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

#84

Reminds me of when I was working at the exact same kind of startup and then AWS Cognito got SAML support. I'm not exactly sure what that startup's business model actually was or what yours could be, they got acquihired and enough to pay back the VCs though. Auth really didn't get better since then?

We're bias but we obviously dont think so. Infact, we think its gotten more complicated over the years. Some of that complexity is for the right reasons but that isnt required for everyone and for all use cases

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

#85
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 feels a bit like a nuclear power plant control panel to me, so I'm happy to see an alternative like this pop up.

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

#86
post #74
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 great software, and I am thankful to Redhat for keeping it open source and maintaining it. But I do not believe that a production deployment of keycloak with HA, backups, customization, integrations, upgrades etc. is easy at all. It takes time and planning to get it right. Depending on the constraints, it isn't obvious to me why it would win by default over SaaS alternatives, or simpler on-premises altern…

> HA, backups, customization, integrations, upgrades etc

I confirm that, we had a bunch of problems with upgrades in one product. In long term keycloak introduced more headaches for ops than we devs had implementing integrations with auth0 or okta. That was before KC10.

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

#87
post #32

For anyone else wondering: the frontend depends on NodeJS and the backend is Java. Ooof.

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.

So the core is written in Java. The core is a http microservice that contains the main auth logic + interacts with the database.

The backend API queries the core for sign in / sign up / sessions etc... This can be in any framework, and we decided to choose NodeJS first. Here, the user does not have to interact with Java at all.. just simply use our NodeJS SDK that internally calls the core's APIs

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

#89
I agree that auth is still a damn pain in the ass.

My last two experiences have been with Firebase and Django, both with React front-ends.

I think the state of JWT auth in Django with Rest Framework is dire. I've used the most popular packages (dj-rest-auth, which uses simple-jwt for JWT under the hood) and I've had to tweak way more than I would like to make it all work. I've been shocked to learn that this is not a solved problem in one of the world's most popular web frameworks, and I'd definitely consider using external auth in future projects.

The Firebase experience on the other hand has been outstanding. The front-end SDK is great and so is the documentation. I had to implement SAML SSO for a massive corporate customer using Microsoft AD and was able pull it off in an afternoon without a hitch. The ability to add custom claims and the like is also great - the whole thing feels really feature-complete. But then there's the fact that I don't trust Google with my user data and that I fear that at any time they could start charging onerous amounts for the service, or worse.

In both cases, the most painful bit however has been by far implementing the React front-end. Wiring the views, Redux async actions, etc. That's the part I wish I could get rid of. I see you provide some sort of front-end, but if you provided some sort of adjacent, standalone React library offering views and auth state management out of the box you'd surely get my attention - I'd possibly consider contributing code to it, too.

Overall I think the whole idea sounds great and you may be on to something: in summary, I feel that Google can't be trusted, Auth0 looks eye-watering expensive, Keycloak looks a bit complicated for certain projects, and popular web frameworks like Django may not be as good at token auth as we would take for granted.

I must be honest in that I wouldn't put your tech into production right now because I'm never a tech early-adopter, but I'll keep an eye on it, I'll seriously consider it for personal projects, and if it gets decent momentum in a few months I'll definitely consider extending it to client projects.

Congratulations for launching - I really, really wish you the best of luck.

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

#90

I agree that auth is still a damn pain in the ass. My last two experiences have been with Firebase and Django, both with React front-ends. I think the state of JWT auth in Django with Rest Framework is dire. I've used the most popular packages (dj-rest-auth, which uses simple-jwt for JWT under the hood) and I've had to tweak way more than I would like to make it all work. I've been shocked to learn that this is not a…

Which SDK/package did you use for Firebase and React? There seem to be half a dozen and ReactFire the most dated?
Post reply on HN