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

141–150 of 347 posts

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

#141

Post by linsomniac »

agilob wrote: post #86
n_kr wrote: post #74

Earlier quoted context omitted.

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.

Curious what sorts of headaches there were in this. We're currently in the process of implementing KC12 using the docker image, a User Storage SPI (our users exist in our legacy master database which is synced from an external billing system), and it's looking so far like it'll be a fairly simple setup. This is basically just acting as a OAuth shim between our primary database and an external service provider in our case, which I imagine keeps the complexity down. But I'm wondering what you might have run into that we haven't yet. Thanks!

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

#142

Post by arcturus17 »

samirsd wrote: post #130
arcturus17 wrote: post #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…

totally agree with you re: django jwt. i actually migrated (back) to firebase auth after several afternoons spent debugging a brittle django auth implementation. i partly blame my own inexperience for that... but i see no reason to bother with django auth anymore as firebase has been rock solid with minimal intervention.

Eh... Don't blame your inexperience. I'm also new to Django but not to web dev, and it's been a pain the ass. I haven't been stuck with any Django aspects (great framework otherwise) but rather issues with the libraries.

In the end I think I will make it work, and robustly. So I don't want to diminish the work of all the open-source devs who have worked on those libraries; I count my lucky stars that they're available in the open and for free.

But it's been painful nonetheless, and I am shocked that a better and more streamlined dev experience is not available, especially in such a popular stack.

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

#143

Post by lmeyerov »

Getting Django would be amazing, speaking as a user for whom Keycloak was interesting except not trusting IBM/RedHat as safe & responsible stewards. And we're exactly in that market of 'we want the OSS + on-prem friendly variant for our on-prem users, but a managed service provider for our managed tier.' Auth0 and friends show how big this market is, and the general push to SaaS-only by them and their competitors has been a non-starter. Smart!

Unfortunately the focus on nodejs / non-django backends means we won't be evaluating for now -- despite being actively looking at this space. But if you or others become active here, am interested. See replicated.com -- implementing API tokens, RBAC, etc. is necessary for teams like ours yet largely generic, so a good OSS-native partner to pick up where frameworks like Django fall down would be awesome. Good luck!

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

#144

Post by advaitruia »

arcturus17 wrote: post #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…

If you remember what you had to tweak for Django JWT auth - please do share. It would be interesting to hear your experiences.

In terms of implementing the react frontend, this is a common complaint:

We do have a react SDK that provides React components for login / sign up UI and its one of our powerful differentiators. It also does not need redux since the login components can handle state easily within themselves. That being said, one possibility to use redux would be to check if the user is logged in or not. For that, we provide a function from the SDK that can be called (doesSessionExist) anywhere in your react app. Hopefully this gets your attention :) Either way, we'd love to hear from you on our Discord or on my email ID (search Advait on this thread).

Your summary is incredibly on point and is part of our core thesis! Thank you for your candid feedback (we are also already in production environments but I understand your hesitancy).

Thank you so much for the encouragement - it is highly appreciated!

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

#145

Post by advaitruia »

ForHackernews wrote: post #123

How does this compare to Keycloak? https://www.keycloak.org/

Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak:

In general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one (but this is not true for everyone).

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 less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).

Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.

We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.

If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.

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

#148

Post by advaitruia »

mfbx9da4 wrote: post #147

My specific need is passwordless login (via email currently) to issue private keys for multi device end to end encryption. If you can do that, I'm in!

We had actually implemented email passwordless for our own website earlier. We havent launched it yet but are hoping to do so. i'd love to update you when we launch it. Please share your email ID or drop me an email at advait at supertokens.io and I'd be happy to let you know when we have it.

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

#150

Post by advaitruia »

tziki wrote: post #146

Out of interest, what's your plan for making a living with an open source product?

We will monetize features that are required by large enterprises. Features needed by developers / startups will largely be free. We have a pricing philosophy section on our pricing page that goes into more details about this :)
Post reply on HN