feat: switches lucia auth with next-auth

[ixahmedxi]

This PR attempts to implement the switching of the authentication from using lucia auth to next-auth, this is due to various reasons:

• Next auth got new docs so it's a bit less alien to figure out how to do things.
• Next auth is much simpler to implement different authentication providers and methods, as a starterkit template this makes it much easier for consumers to implement their own authentication providers.
• I also dropped the google provider in this because it makes things a lot simpler for us in terms of documenting things & it's just very easy to add into next-auth when you decide that you need it.
• Next auth supports preview deployment oauth, implementing that from scratch would be a bit tedious.

[ixahmedxi]

TODO:

• Change up the documentation to reflect the changes.

[shadizx]

just fyi: i found the performance of lucia to be better than next-auth.

also, as a starter kit it makes more sense to use lucia. the main pain point I hear with using lucia is that it takes a long time to set up. the whole point of a start kit is to fix that, so it makes sense to go through the effort of setting up lucia once, and benefit from the added freedom and performance.

[imCorfitz]

It begs the question who will be using OrbitKit. Next Auth for sure is a lot easier to customise, but in return also very opinionated compared to Lucia.

Next auth is much simpler to implement different authentication providers and methods, as a starterkit template this makes it much easier for consumers to implement their own authentication providers.

This is a valid point, if we consider that the average developer with OrbitKit just wants to spin up an auth client and deploy. However as @shadizx points out, OrbitKit could help by being the first step to a more flexible (and in my opinion more proper) auth solution.

Next Auth (IMO) is for developers that don't want to deal with Auth. They want to a solution that "just works". Lucia on the other hand is for those who wish to have more control of their auth system. A set of helpers to facilitate rather than dictate their auth flow.

OrbitKit is an opinionated starter kit (when it comes to technical choices), however everything in the repo follow the principle of allowing the developers to create anything they want without limitations. Is Next Auth adding a limitation? Does the possibilities Lucia brings outweigh complexity in building the boilerplate?

---

Now, another question would then be: "Is there a way to do both?". Since it is a monorepo, there are always room for another package. And the question then is, if it would be possible to use turbo generators to help with a transition between the two.

[duttaoindril]

I just found out about orbit-kit; I would strongly not support moving to nextauth exclusively - it should be a user option, like the t3 stack supports prisma and drizzle. I personally prefer lucia.

[ixahmedxi]

I think based on the feedback that I have gotten from this, I will be sticking with lucia auth. I have also found in my testing that next-auth does a lot more db calls which isn't great. Thank you all for the feedback.

I will be closing this PR now. The next steps in this authentication story is to have email + verification codes authentication and I think these 3 methods (google, github and email verification codes) would be the auth methods shipped and configured by orbitkit by default.