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!
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!
On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website).
Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io
Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)
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.
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)
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.
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.
I installed two popular libs, tweaked some code in the back, rolled out my front-end, and came up with a robust solution. In my opinion, I wouldn't have saved any time implementing your proposed design if I understand it correctly (especially on the front-end), and I'm not sure about its overall robustness since I don't like at all the idea of periodically polling from the front-end to check the state of the token, as opposed to automatically attempting a refresh on certain response conditions. But that's just me...
Regardless, my original point is that one shouldn't be spending much time at all on a commodity feature like this. I wish I could've spent 80% of that time writing real business logic and interfaces.
> I'm really not sure that a refresh token on the front end actually provides that much security.
Compared to any other mechanism where tokens are revokable (ex: hitting the db), no, it doesn't provide additional security.
Compared to non-revokable tokens it provides loads of additional security, without compromising on UX... The refresh token allows for short access token lifetimes (I have them at ~5min, same as Google has on Firebase), while providing the possibility of keeping the user logged in for weeks and having a revokation mechanism if it all goes south.
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.
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?
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.
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.