feat: add more auth options to the CLI

[MahmoudESSE]

Is your feature request related to a problem? Please describe.

I noticed that we only use nextAuth or choose none to start with no auth, then either add an auth service manually or develop without auth.

Describe the solution you'd like to see

Add clerk to auth option as a start just like drizzle was added to the ORM list to quickly setup clerk using the CLI instead of manual setup.

Describe alternate solutions

.

Additional information

Maybe later add other auth method besides clerk and nextAuth but for now this one the ones I see been used often, so I wanted to know if this is a desirable feature to add to the CLI.

[mqshaikh8]

This sounds interesting. I wonder if that is in the plan for this tool. I would love to do this if it something that is planned and no takers.

[juliusmarminge]

We are considering adding Clerk and/or Lucia but still nothing definite.

[ronanru]

I really like Lucia for auth, can I make a PR that adds it as an option?

[MahmoudESSE]

I read on an old issue that there were plans for "add on" plugin for auth, can you provide examples or idea of how we should implement it

[juliusmarminge]

I really like Lucia for auth, can I make a PR that adds it as an option?

cc @c-ehrlich @nexxeln what'ya think?

[dBianchii]

I thought that one big ethos of t3-oss was to honor the last part of the name... -oss.

Although, I see that if we still have the option to choose open-source alternatives, then technically it is still honoring that

[c-ehrlich]

I really like Lucia for auth, can I make a PR that adds it as an option?

cc @c-ehrlich @nexxeln what'ya think?

id be up for it. but @ronanru maybe first make an example repo(s) for what output apps would look like - to keep it small, maybe /pages + prisma and /app + drizzle. gives us something to look at / talk about with less initial effort.

[ronanru]

I really like Lucia for auth, can I make a PR that adds it as an option?

cc @c-ehrlich @nexxeln what'ya think?

id be up for it. but @ronanru maybe first make an example repo(s) for what output apps would look like - to keep it small, maybe /pages + prisma and /app + drizzle. gives us something to look at / talk about with less initial effort.

Made a quick output example.
/app + drizzle and /pages + prisma + trpc
https://github.com/ronanru/t3-lucia

[raphaelm-gioa]

Waiting on Auth.js to drop so we have a Expo/Next.js connector merged to it - and finally have a React Native/React connector !
Lucia sounds fair also ! I believe ct3a should support Clerk as well as self-hosted solutions - we're all about no lock-in ! (Using Clerk in all my pro projects btw, no shade here, it's an amazing tool)

[RobSchilderr]

What about Supertokens? It's similar to Clerk but has a self-hosted option.

[rishabhpoddar]

As a follow on to what @RobSchilderr said, we can also offer users the choice of adding different types of auth to their app:

• email password
• social login
  • For social, we can also offer them a pick of google, fb, github oauth and provide dev credentials which work right out of the box (which users should replace before pushing to prod)
• passwordless (magic links, OTP)
• any combination of the above

This choice can be from the CLI itself, and the generated app has the relevant config already setup for their chosen auth method (and in case users are not sure which method they want, we can just default to email password).

Regardless of SuperTokens being added, I think allowing users to pick a specific auth method will be cool.

[Wundero]

As a follow on to what @RobSchilderr said, we can also offer users the choice of adding different types of auth to their app:

• email password

• social login

  • For social, we can also offer them a pick of google, fb, github oauth and provide dev credentials which work right out of the box (which users should replace before pushing to prod)

• passwordless (magic links, OTP)

• any combination of the above

This choice can be from the CLI itself, and the generated app has the relevant config already setup for their chosen auth method (and in case users are not sure which method they want, we can just default to email password).

Regardless of SuperTokens being added, I think allowing users to pick a specific auth method will be cool.

I personally don't see why this would be a necessary addition to the CLI tool - NextAuth, Lucia, etc. all provide fairly straightforward ways to customize the providers (email, oauth, etc.) that you can use as they are, so having a choice in the CLI tool saves very little time and bloats the code of create-t3-app. Additionally, you can usually use more than one at once, and that increases the complexity further of integrating that into the CLI. IMO good examples and documentation are better in this case than more CLI options.

Separately, providing "dev credentials" for oauth isn't really feasible, since oauth requires you to setup your app by the providers, and even if it was feasible, it would be pretty insecure. oauth is really strong because it's really easy to use to sign in with real accounts, so dev credentials can just be whatever provider you use (github, discord, etc.).

[rishabhpoddar]

NextAuth, Lucia, etc. all provide fairly straightforward ways to customize the providers (email, oauth, etc.)

Yup, however, it's just one less friction point for users to get what they want. In order to customise these solutions, users would need to dive into the docs of these auth providers, which can be annoying. But I understand that it will make the CLI code a bit more complex.

Separately, providing "dev credentials" for oauth isn't really feasible, since oauth requires you to setup your app by the providers, and even if it was feasible, it would be pretty insecure

There is a way to make it work for any domain by introducing a proxy domain in the middle. This IS a security issue indeed, which is why we should somehow enforce that these credentials are only used for dev builds. Again, the aim here is to get people started as quickly as possible.

[c-ehrlich]

we are definitely never adding credentials auth. if someone wants to implement it in their app, that's on them. the effort of reading one page in the next-auth docs is tiny compared to the actual work that is required to make something that is secure and fits the greater needs of their project. having it as a CLI options is leading people down a dangerous path.

our goal is to give you a next-auth implementation that is integrated with Next, tRPC, Drizzle/Prisma, etc, but not tell you what your entire auth setup should look like. the reason for the discord provider is that it requires the least amount of work to get from zero to something, but almost nobody will keep using discord for auth when they build a real app. users having to swap it out is a feature, not an oversight.

[juliusmarminge]

What about Supertokens? It's similar to Clerk but has a self-hosted option.

I dont think anyone on the core team has tried that and we're only adding stuff we're comfortable to recommend to others so it's currently Clerk and NextAuth, maybe Lucia

[henrikvtcodes]

I would like to +1 Lucia here, since it seems to fit well within T3, specifically because it is similar to NextAuth/Auth.js in that it runs within Next.js - a notable difference between it and something like Clerk, Supertokens, etc. Adding Clerk or a different hosted auth provider seems like it would overcomplicate things, because the end-user/developer would have to go set it up and get API keys for the hosted service in addition to getting the Client ID and secret for their OAuth provider(s) of choice before they can run the dev script and get going.

[rishabhpoddar]

in addition to getting the Client ID and secret for their OAuth provider(s) of choice before they can run the dev script and get going.

Won't that be true for any auth solution (including nextauth)? Unless of course, the generated app uses oauth credentials that relies on a proxy domain.

[henrikvtcodes]

Won't that be true for any auth solution (including nextauth)? Unless of course, the generated app uses oauth credentials that relies on a proxy domain.

Well yeah you always need a client ID and secret no matter what oauth solution you use, but my point was that NextAuth/Lucia dont need any other API keys or anything since they are not external to Next.js.

[cfarvidson]

I would like a clerk add on. (I have never tried Lucia)

I just finished adding clerk to a T3 project (trpc, typescript, prisma, tailwind) and it was not trivial (for me at least) to get everything to work. And by work I mean working auth in both client and server side components when using trpc queries.

[juliusmarminge]

Hey everyone,

We have decided not to pursue adding Lucia auth as we believe it's too similar to next-auth (especially with v5 around the corner and it's auth.js port).

Will keep this issue open until we've made a definitive answer on adding clerk or not.

[RobertHH-IS]

@cfarvidson I am also having a difficult time integrating clerk into the unique t3 trpc setup. Any way you would post the main parts of the deployment?

[rishabhpoddar]

Is there interest in adding other auth providers like SuperTokens?

[ielm]

@RobertHH-IS there's an example project by @perkinsjr for integrating clerk into t3 trpc here. It's based on the pages router, but still helpful.

I would also like to +1 adding clerk auth to create-t3-app. I think most people using t3 are opting for next-auth or clerk, and getting clerk to play nicely with trpc is a little painful.

For anyone interested in this in the meantime, clerk provides documentation for pages router integration here.

EDIT: I've created a sample repo here if you need help setting up clerk. Note that you need to create a clerk app first and add the publishable and secret keys to your .env.

[rpatel15-hue]

Here are my thoughts: Many users of create-t3 are focused on quickly shipping and iterating on their projects. A challenge emerges, for example, when a project scales and there's a shift towards developing a React Native application. At this point, next-auth proves to be incompatible with React Native. Introducing support for alternatives like Lucia, and possibly Clerk (despite it not being open-source), could offer a seamless transition. This strategy would prevent users from having to undertake extensive refactoring when they decide to expand their projects.

[juliusmarminge]

A challenge emerges, for example, when a project scales and there's a shift towards developing a React Native application. At this point, next-auth proves to be incompatible with React Native. Introducing support for alternatives like Lucia

This statement is just not true. next-auth supports react native auth in the exact same way as lucia does

[rpatel15-hue]

@juliusmarminge You are right, I knew about next-auth but did not know about lucia. For some reason, I thought they did. Here are the two sources I read:

• Next Auth: https://github.com/nextauthjs/next-auth/blob/72ba83c3ee9a78b1bccac2a2629b76a073ede3be/docs/docs/concepts/faq.md?plain=1#L78
• Lucia: RFC: Support native apps with bearer token support lucia-auth/lucia#652

[Syarx]

I am willing to try and implement lucia in ct3a as it is at the moment, would that be allowed to merge if it is up to the standards?

[ronanru]

I am willing to try and implement lucia in ct3a as it is at the moment, would that be allowed to merge if it is up to the standards?

#1593 (comment)

[willredington]

I am definitely in favor of this. Next-auth just never does quite everything necessary. The non-beta version doesn't do refresh tokens and doesn't work well with keycloak, and the newer iteration looks promising but its still very much early stages. Clerk on the other hand seems more robust

[lorensr]

@juliusmarminge would a PR adding a Clerk option be welcome?

[astridlol]

@juliusmarminge would a PR adding a Clerk option be welcome?

Clerk is so incredibly easy to set up, that I don't really see a reason for this.
It's as simple as pasting two env vars, adding a middleware.ts and putting ClerkProvider in your root layout or _app.ts.