Live data from Hacker News

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

news.ycombinator.com

71–80 of 347 posts

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

#73
post #72

Hi, just FYI, I saw that you are setting third party cookies without consent. While I generally don't like the flood of cookie banners, it's a legal requirement if you are accepting EU customers.

Thanks for the heads up!! We will fix this ASAP.

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

#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 alternatives like OP's.

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

#75
post #6

Sick of spending your time on auth, you decided to spend all your time on it?

If a thing annoys you it'll probably annoy a lot of people that are probably willing to pay to solve the problem.

It annoys me for sure and which it were simpler. What I found when integrating SAML is you have to work with whatever login code you already have which will build in assumptions across your app.

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

#76

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 never did it, what is a good guide to start? Thanks!

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

#78

Considering the number of problems that arise when someone confuses "authentication" with "authorization", it makes me slightly queasy to see something claim a focus on "auth". :/

Hahahaha. Fair enough. And it get's even worse when talking about sessions and tokens...

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

#79

I would absolutely consider this once email verification exists for new accounts. But not until then. It looks like a good feature set and yes, I would love to use a solution from someone who focuses on auth vs. rolling my own. I do think your documentation could be expanded. You have some examples of how to use it with Netlify, but I'd love to see example apps for other cloud providers as well (Heroku, in my case.)…

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!

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

#80

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 hate doing auth and commodity features like user admin along with SSO integration, and hooking it all up to both the front and back end. I'd rather be busy doing business related features.
Post reply on HN