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

101–110 of 347 posts

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

#101

Post by mooreds »

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've identified), why wouldn't I use a language specific library (devise for rails, passport for js, etc). Or is the value that you're providing a modular integration so I don't have to integrate authentication + authorization + user management + API auth myself?

Anyways, congrats on launching. We need more auth solutions and I'm glad to see an interesting approach in the open source world. The other major contender, KeyCloak, is, I've heard, a bear to run and extend.

Full disclosure, I'm an employee of FusionAuth.

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

#102

Post by nicoburns »

rishabhpoddar wrote: post #30
munchbunny wrote: post #22

Interesting idea! I did a quick look through your site and have a few issues: 1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection? 2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this? 3. Password reset emails come from @su…

1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD. 2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead. The issue with that is that there might be CSS clashes and to prevent that, we use shadow-root (HTML feature). On certain browsers, password managers do not work with a shadow-root…

> On certain browsers, password managers do not work with a shadow-root.

Eek. Worse than that, certain browsers (e.g. IE11) don't support Shadow DOM at all! You may wish to consider widening your browser support.

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

#103

Post by advaitruia »

corytheboyd wrote: post #92
advaitruia wrote: post #82

Earlier quoted context omitted.

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!

Part of it too is that I tend to work on smaller projects that don’t grow and change indefinitely like startup saas does. If you’re getting something up quickly where the requirements will change all the time, a service like this starts to make way more sense :)

Yes, thats exactly it - from our experience with talking to devs and startups. Once the project starts scaling, things change

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

#104

Post by mooreds »

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…

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

What, Google would never do that :)

But seriously, I think that developer focused solutions are safer than other products, especially if they are tied to revenue and are fully established.

A quick scan of https://killedbygoogle.com/ shows a few dev focused products, but more consumer focused ones.

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

#105

Post by rishabhpoddar »

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.

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

#106

Post by rboyd »

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

Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak: 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 les…

Is SuperTokens multitenant capable? My understanding is that keycloak suffers in a multitenant enviroment with a sufficiently high number of tenants.

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

#107

Post by sidhuko »

> We think that Auth0, Firebase etc are great services but auth is complex.

Yep that tends to happen when you are supporting SSO and certifications like OpenID Connect. Using one SSO portal to handle mobile, spa, web apps and code auth with evolving techniques like PCRE. That's probably why some customisations are not available too because it breaks the standard. You will just end up with the same models once you've implemented all the same features. Okta, Auth0 and others are all really similar because of the standards behind them not because they thrive to be complex.

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

#108

Post by rishabhpoddar »

nicoburns wrote: post #102
rishabhpoddar wrote: post #30

Earlier quoted context omitted.

1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD. 2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead. The issue with that is that there might be CSS clashes and to prevent that, we use shadow-root (HTML feature). On certain browsers, password managers do not work with a shadow-root…

> On certain browsers, password managers do not work with a shadow-root. Eek. Worse than that, certain browsers (e.g. IE11) don't support Shadow DOM at all! You may wish to consider widening your browser support.

Oh! Thanks for the heads up! I have created an issue about this on our github, referencing this comment.

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

#109

Post by arcturus17 »

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

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

The official Google Firebase SDK... I didn't know there were third-party SDKs. All the React layer (views, state management, etc.) was my own.

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

#110

Post by mattbrewsbytes »

I had to scroll thru the website, find docs then click thru to the quick start to discover that this is nodejs. Put the tech used on the front page.

You may want to hold back the "Stripe for Auth" tagline until you have more languages implemented. Also you aren't competing with things like Auth0 because if an organization has money for Auth0 why would they roll their own? You are competing with all the different open source framework implementations for Auth.

Post reply on HN