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

151–160 of 347 posts

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

#151

Post by advaitruia »

ignoramous wrote: post #140

I hear you. The need for something simple is real. I don't have a complex SSO/Auth need, and so, something as simple as single-factor FIDO based passwordless login (such as sawo [0] / portier [1]) or hands-off user management (like userbase [2] / human-id [3]) cuts it for me. That said, the only question I have is the GitHub page says SuperTokens is "open core" > SuperTokens is an open core alternative to proprietary…

Everything we have today is open source. However, in the future, we plan to monetize features that would be required by enterprises. At that point, we'd be an open core company where a large part of the software would be open source but a few features would be proprietary.

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

#152

Post by advaitruia »

timwis wrote: post #149

Can you confirm that you don’t recommend storing session tokens in localStorage / anything accessible by client-side JS? (It’s a commonly recommended bad practice these days)

Yes, we do not recommend storing tokens in localstorage. This is also recommended by other security bodies such as OWASP and NIST. We've written a blog post on this topic as well, that you can read here:

https://supertokens.io/blog/cookies-vs-localstorage-for-sess...

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

#154

Post by timwis »

advaitruia wrote: post #152
timwis wrote: post #149

Can you confirm that you don’t recommend storing session tokens in localStorage / anything accessible by client-side JS? (It’s a commonly recommended bad practice these days)

Yes, we do not recommend storing tokens in localstorage. This is also recommended by other security bodies such as OWASP and NIST. We've written a blog post on this topic as well, that you can read here: https://supertokens.io/blog/cookies-vs-localstorage-for-sess...

Great! Pleased to see this :)

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

#155

Post by leesalminen »

anonytrary wrote: post #111
corytheboyd wrote: post #69

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…

Yeah I don't mind setting up auth. It takes like a week at most for your MVP.

I’m building a MVP to show off and validate some ideas. I’m using Firebase and set up auth with my react app in about 10 minutes. I’d never spend a week on auth for a MVP.

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

#156

Post by nullsense »

frenchman99 wrote: post #129
anonytrary wrote: post #111

Earlier quoted context omitted.

Yeah I don't mind setting up auth. It takes like a week at most for your MVP.

Depends what you mean with "setting up auth". Once you get into enterprise scenarios, where you need SSO for SSH, Git, your public website, internal tools, ability to revoke accesses, handle trusted mobile devices (ie generating QR codes for VPN/Wireguard access), handling 2FA, etc, etc, it takes more than a week. For such scenarios, doing it yourself and doing it correctly becomes immensely difficult.

Agreed. Done right it's a huge time suck.

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

#157

Post by leesalminen »

rubicon33 wrote: post #53
codingdave wrote: post #3

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

Firebase Auth. One and done.

Can confirm. Just built out a little react MVP using firebase. Auth took mere minutes.

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

#159

Post by arcturus17 »

advaitruia wrote: post #144
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.…

Sure, dj-rest-auth + simple-jwt implements JWT with http-only cookies by default, which I have embraced. Except that when you refresh the token, it no longer returns and http-only cookie (it returns the access token in the response body) due to an issue with how the two aforementioned libs interoperate. So the dev has to patch that in manually with their own code, otherwise the full token cycle is not http-only. Isn't that weird?

Other issues include wiring some routes (urls, as Django calls them) so that they properly triggered password reset emails.

I want to insist that none of this has been the end of the world, and extend my eternal gratitude to the authors of the libs, but I guess I was shocked to encounter this in a framework as mature as Django (I've moved to it in search of stability compared to the Node.js ecosystem, which I feel is the wild west in some respects and not as suitable for the types of web apps I develop)

The other (more time-consuming) issues have been with implementing the front-end bits like I mentioned. An axios interceptor for refresh tokens, state management with Redux, the views (ugh, I love writing React but I really don't want to create another login form).

I'll definitely take a look at your React code tomorrow, and I may be able to provide some additional feedback (and maybe steal some ideas too)

Also, I want to commend your effort in marketing / comms - I've seen you both on Reddit and here, and this second impression on HN is what has prompted me to comment. Tbh first time I saw you on Reddit I thought this was more of a toy project but here on HN it's definitely clicked that you guys are serious.

I've starred you on Github, I'm watching for new releases, and I'll mention you to my friends, but I think you should definitely keep up your active communication efforts - it's worked for me at least.

Again, best of luck, and greetings from Spain!

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

#160

Post by jrockway »

corytheboyd wrote: post #69

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 am annoyed at doing auth over and over, when it's other people's software. The promise of the container revolution was that cross-cutting concerns would be handled by the infrastructure / orchestrator, and applications wouldn't have to care about details like authentication, monitoring, logging, etc. None of that really materialized, though. The actual running/scheduling of workloads is currently in a great state, but the cross-cutting concerns are pretty awful. Or actually, they're good, but very much "bring your own". I use managed Kubernetes, but it doesn't give me managed monitoring, managed logging, managed authentication, etc. (Cloud providers sell that, but you have to do all the integration work. Some random Go binary you download won't accept Identity Aware Proxy JWTs and send your metrics to Stackdriver. You have to make that all work yourself.)

I've run into the situation at least twice where some app has bought into that mindset and made auth an external factor (don't send HTTP requests unless the user is authorized), and found that there was pretty much nothing good to provide that feature. So... I wrote my own thing both times, and am loving it. (You could use it too! But I wouldn't necessarily recommend it: https://github.com/jrockway/jsso2) I never have to think about auth again.

Having also done the infrastructure and library work to get Prometheus/Grafana/Jaeger/Loki doing what I want (https://github.com/jrockway/opinionated-server), I am almost happy with the remaining cross-cutting concerns. I am ever closer to my "1 hour app", where I can just type in some code and have a fully-working production-quality app available to users. I'm not there, but I'm getting closer by the year.

(Sometimes I wonder if we were wrong to totally get rid of the "just rsync some PHP files to a server" model. There were good things and bad things going on there; we should bring the good things back.)

Post reply on HN