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

191–200 of 347 posts

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

#191

Post by sundarurfriend »

Aeolun wrote: post #187
advaitruia wrote: post #182

Earlier quoted context omitted.

Sorry, I am not sure I completely understand. When you say that we may not be able to provide because it would be expensive - do you mean it would be expensive for us to build or for startups to buy? What exactly would the catch 22 situation be?

If I need to pay to access the enterprise features (just like with Auth0 or Cognito), why wouldn’t I just use those?

More customizability, benefit from the open core model, an easier on-ramp to try out and get used to the product.

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

#193

Post by AsyncAwait »

mooreds wrote: post #183
rishabhpoddar wrote: post #105

Earlier quoted context omitted.

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.

So if you are aiming to be full featured, the modularity plus open source is your differentiator? What are you going to do if AWS/GCP/Azure decides to offer a managed services version of your software? (I know, I know, that'd be a a great problem to have.)

AWS etc. already offer these services so the risk is low. I dislike the recent trend of companies changing licenses from a formerly FLOSS solution to "source available".

It prevents little in practice and makes it so that your original differentiator i.e. open source is no longer true.

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

#194

Post by sundarurfriend »

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.

> a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect

Baseod on the rest of your comment, I think maybe deplorable was not the word you intended to use there?

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

#195

Post by ehutch79 »

arcturus17 wrote: post #127
ehutch79 wrote: post #116

Earlier quoted context omitted.

I would honestly question if you actually need JWT anyways. jwt is useful for independently verified auth tokens. i.e. service a auths the user, generates a token that says ' this is definitely my user with this data'. service b can't auth the user because it has not access to the data, but can trust the jwt from service a. every time i've seen someone with a jwt issue in django, they've just been wrapping the sessio…

I've read plenty about the limitations and security risks of JWT so I'll take the criticism in that sense. However I've implemented them a really hardened way (http-only cookies, not storing anything in localStorage, short token lives, revokable refresh tokens, etc.) so I'm pretty sure it'll be fine. The thing is, I looked into other auth alternatives (sessions, regular tokens) for Django DRF + React and they all see…

I'm definitely not questions if your doing things securely or not. Just if maybe needlessly complex.

I'll describe what i'm doing, as the code is kind of old.

* I have a token model that stores a uuid and the relevant user and data, along with an expiration. This isn't session data, just the valid token. You can also store this in redis or wherever.

* There is an endpoint that takes a username and password, and if valid, generates a token, and sets the token's id as a httpOnly secure cookie. This can also returns basic user data for display, name profilephotourl, global permissions, etc. This has a noauth decorator from DRF

* there is a check token endpoint which just returns the above data. This also updates the expiration.

* i have auth module based on rest_framework.authentication.BaseAuthentication that checks the cookie, token validity, etc and generates a valid user.

That's a high level overview.

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

#196

Post by ehutch79 »

ehutch79 wrote: post #195
arcturus17 wrote: post #127

Earlier quoted context omitted.

I've read plenty about the limitations and security risks of JWT so I'll take the criticism in that sense. However I've implemented them a really hardened way (http-only cookies, not storing anything in localStorage, short token lives, revokable refresh tokens, etc.) so I'm pretty sure it'll be fine. The thing is, I looked into other auth alternatives (sessions, regular tokens) for Django DRF + React and they all see…

I'm definitely not questions if your doing things securely or not. Just if maybe needlessly complex. I'll describe what i'm doing, as the code is kind of old. * I have a token model that stores a uuid and the relevant user and data, along with an expiration. This isn't session data, just the valid token. You can also store this in redis or wherever. * There is an endpoint that takes a username and password, and if va…

on the front end i just hit that check_token endpoint every five minutes or so.

I'm really not sure that a refresh token on the front end actually provides that much security.

Also, this is all just one way of doing it.

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

#197

Post by madjam002 »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login.

I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!

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

#198

Post by sebmellen »

movedx wrote: post #188

For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem. If someone loses access to an email account then I can use manual processes to verify the person and change the email…

There's a great project called Portier [0], which does this quite nicely. I highly recommend it.

It's a successor of sorts to the ill-fated Mozilla Persona project [1].

> Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.

[0]: https://portier.github.io/

[1]: https://en.wikipedia.org/wiki/Mozilla_Persona

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

#199

Post by reidjs »

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?

If you want a very basic implementation here’s a repo I made to hook the real-time db to react. Don’t know if it’s helpful for what you’re looking to do.

https://github.com/reidjs/react-firebase-input

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

#200

Post by tracker1 »

mbullington wrote: post #133

SuperTokens looks really cool and I'm glad it's open source, however, I think the big "blue ocean" here for self-hosted auth systems vs. AWS Cognito and Auth0 are security compliance. Many large orgs with data requirements need things like ISO 27001, FedRAMP, etc. If you build with a product like SuperTokens and then need to meet these requirements later in your development lifecycle, you'll have to: a. switch to Cog…

Funny, I actually wrote a relatively simple auth system that does meet NIST guidelines (by default) and some other security requirements. It sends a JWT token for application usage and can register multiple applications for support, not full OAuth etc. The main application it's used with also integrates into other third party apps, so needed a simple means in-app for auth.

I tried to get permission to develop/publish this application as open-source, but was never able to do so. It's now got a few rough edges only because without the public need/perception some bits aren't as well flushed out beyond our internal use/needs and or the needs of our deployed instances. Not to mention a few requirements to satisfy a difficult architect/lead on another team, and they wound up not using the app anyway.

It's not too hard to meet some guidelines... I wound up using a simple KV pattern for data storage so I could target different adapters, add overlays for caching and encryption etc. There's some cool bits and some muddled bits.

Post reply on HN