31 ms·
How does this differ from next-auth? Does that support Firebase? Somehow I feel like writing custom packages for integrating a 3rd party SaaS might be an anti-
by moritzwarhier 2y ago
How does this differ from next-auth? Does that support Firebase?
Somehow I feel like writing custom packages for integrating a 3rd party SaaS might be an anti-pattern (or sth like this, the word is annoying in its inherent generalization).
Doesn't Firebase already support some kind of auth (integration) that is supposed to be easy to integrate with frontend libraries?
Auth is the part of any application where I would do the biggest effort to minimize the amount of external packages (but not to 0, not rolling own crypto etc for sure), stick to defaults, and try to be aware of any security caveats in my system.
- nirmalscaria 2y agoNext auth does support firebase as a provider. But firebase itself does support all the common providers. So you really either need firebase, or Next Auth. Not both. Firebase could really replace Next Auth, as the providers aggregator (I guess). Relying completely on firebase is a strong possibility for nextjs, as far as I could see. Next Auth, while offers a lot of features and flexibility, is known to be a pain to set up. Firebase, while offers easy setup, doesn't support most rendering patterns of NextJS. I think this is the reason NextJS devs usually stay away from Firebase as the go-to auth solution. Then there were all the stuff that could be abstracted, like cookies, routing and all. None of these were officially provided by Firebase for NextJS. This was the main motivation for the project. I thought there might be devs like me, wanting to just setup some auth provider, without worrying about where the data is stored, what tokens are used, and all. I completely understand developing an open source project for Firebase is an anti-pattern. Honestly, I didn't really give much thought into "What if firebase wants to do an official one." I guess we'll see. :P