5 ms·

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 o

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 solved problem in one of the world's most popular web frameworks, and I'd definitely consider using external auth in future projects. The Firebase experience on the other hand has been outstanding. The front-end SDK is great and so is the documentation. I had to implement SAML SSO for a massive corporate customer using Microsoft AD and was able pull it off in an afternoon without a hitch. The ability to add custom claims and the like is also great - the whole thing feels really feature-complete. 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. In both cases, the most painful bit however has been by far implementing the React front-end. Wiring the views, Redux async actions, etc. That's the part I wish I could get rid of. I see you provide some sort of front-end, but if you provided some sort of adjacent, standalone React library offering views and auth state management out of the box you'd surely get my attention - I'd possibly consider contributing code to it, too. Overall I think the whole idea sounds great and you may be on to something: in summary, I feel that Google can't be trusted, Auth0 looks eye-watering expensive, Keycloak looks a bit complicated for certain projects, and popular web frameworks like Django may not be as good at token auth as we would take for granted. I must be honest in that I wouldn't put your tech into production right now because I'm never a tech early-adopter, but I'll keep an eye on it, I'll seriously consider it for personal projects, and if it gets decent momentum in a few months I'll definitely consider extending it to client projects. Congratulations for launching - I really, really wish you the best of luck.

simonbarker87 6y ago
Which SDK/package did you use for Firebase and React? There seem to be half a dozen and ReactFire the most dated?
- arcturus17 6y ago
  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.
  - simonbarker87 6y ago
    Thanks
- reidjs 6y ago
  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 https://github.com/reidjs/react-firebase-input
mooreds 6y ago
> 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/ https://killedbygoogle.com/ shows a few dev focused products, but more consumer focused ones.
- arcturus17 6y ago
  Firebase auth itself is mostly free though - only phone-verified authentications are paid. I don't think they'd kill it but I wouldn't be surprised if they started charging on par with Auth0. And if they're not charging for it, then what is the product? I mean, I know that they charge for other parts of the Firebase stack, but why offer a best-in-class authentication solution mostly for free?
ehutch79 6y ago
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 session id from django in a jwt, and then unwrapping it and verifying it in the db anyways.
- arcturus17 6y ago
  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 seemed just as difficult to implement. That's the sticking point in this whole discussion and what these guys are trying to solve - auth is critical and sensitive, but it's also largely a commodity that in most cases is not relevant to the application business logic, and there's no reason it should take so long to implement every. single. time. (But if you have a tip on how to implement auth in Django + SPA's in a super-easy way that scales horizontally and allows users to stay logged in between sessions, I'm willing to be persuaded that the developer experience for auth doesn't suck so much)
  - ehutch79 6y ago
    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.
savrajsingh 6y ago
considering flask-login for a new project, should I consider firebase instead? I do like most parts of GCP
- advaitruia 6y ago
  Would love to know what is preventing you from considering SuperTokens
samirsd 6y ago
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.
- arcturus17 6y ago
  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.
advaitruia 6y ago
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!
- arcturus17 6y ago
  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!

simonbarker87 6y ago

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

arcturus17 6y ago
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.
- simonbarker87 6y ago
  Thanks
reidjs 6y ago
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 https://github.com/reidjs/react-firebase-input

mooreds 6y ago

> 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/ https://killedbygoogle.com/ shows a few dev focused products, but more consumer focused ones.

arcturus17 6y ago
Firebase auth itself is mostly free though - only phone-verified authentications are paid. I don't think they'd kill it but I wouldn't be surprised if they started charging on par with Auth0. And if they're not charging for it, then what is the product? I mean, I know that they charge for other parts of the Firebase stack, but why offer a best-in-class authentication solution mostly for free?

ehutch79 6y ago

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 session id from django in a jwt, and then unwrapping it and verifying it in the db anyways.

arcturus17 6y ago
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 seemed just as difficult to implement. That's the sticking point in this whole discussion and what these guys are trying to solve - auth is critical and sensitive, but it's also largely a commodity that in most cases is not relevant to the application business logic, and there's no reason it should take so long to implement every. single. time. (But if you have a tip on how to implement auth in Django + SPA's in a super-easy way that scales horizontally and allows users to stay logged in between sessions, I'm willing to be persuaded that the developer experience for auth doesn't suck so much)
- ehutch79 6y ago
  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.

savrajsingh 6y ago

considering flask-login for a new project, should I consider firebase instead? I do like most parts of GCP

advaitruia 6y ago
Would love to know what is preventing you from considering SuperTokens

samirsd 6y ago

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.

arcturus17 6y ago
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.

advaitruia 6y ago

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!

arcturus17 6y ago
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!