Why is there no signup function?

[martinatwainobicom]

Hello,

first I would like to thank you very much for the time and effort you put into this project!
I am not very familiar with authentication and authorization processes so this might be one of the reasons why I struggle with this.

My current understanding is that NextAuth either logs in an existing user or signs up AND logs in a new user with the signin() function. This would mean that I can, at one point in time, signin with the Google Provider and if I forget about that later on, sign in with the Facebook provider. Since there is no automatic merging of these accounts for security reasons I would end up with two distinct users. However, the actual user (now logged in via Facebook) might wonder where all his data is gone. Is this assumption correct?

What I want to achieve is, having a User Login and a User Signup/Registration Page. Users should only be able to log in, if they have first signed up/registered previously. For both pages I would like to use Providers like GitHub for example.

Registration: Create a new user + account in the database AND log in the user.
Signin: Only existing users (in the database) are allowed to log in

In the signin callback I can check whether a user already exists in the database or not by checking for user.id and therefore allow signin or decline it. In the previous example this would mean that, when the user tries to sign in with the Facebook provider, he would get an error message because he has not registered before.

My first attemt was to call the signin function from the login and registration page.
However, I am not able to distinguish whether the Authentication Flow was started from the Registration or the Signin Page, because I call the same signin() function. Which brings me to the starting question, why is there no signup function? Or is there a way to distinguish between a registration flow and signin/login flow?

I haven't found any pointers about that in the documentation or in the issues lists (except for the user merging issues). So I kind of have the feeling that my mental model about how this should work is twisted.

I would really appreciate if you could bring some light into this.
Thank you!

[mhdalmajid]

I was going to ask the same question!
follow up

[j-lee8]

I would love to know the answer to this as well, but I don't think it's possible.

The only way I know is the check the isNewUser flag in the jwt callback, but it's still the same sign in/sign up process.

[advantiot]

This is exactly what I have been grappling with. I planned to use the email id as the user identifier, since I do persist session data in the database. But this will not work since Github and Facebook (the two providers I wanted in addition to Google) do not return the email id if the user does not allow it.

While this is a brilliant library and simplified Google Auth tremendously, I am wondering about the feasibility of offering multiple OAuth providers for applications that need user identification. Or should it be assumed that OAuth works best only for applications that do not care to identify users across providers?

@martinatwainobicom I am not sure about your question so this may not be answering it, but I'll state my understanding, just in case it helps.

While it is the same signIn() function, the first time I call it without parameters and that redirects it to the default Login or Sign In page or the one configured in [...nextauth].js. That page reads the list of OAuth providers and display the buttons for each one. When anyone of the provider buttons is clicked the signIn function is called with the provider id as a parameter (and an optional callback for redirection) which triggers the actual authentication with the provider.

[redimongo]

Would be nice to have a signUp function - or the ability to add it manually afterwards.

[GermanJablo]

That a feature as essential as this is not present makes me think that it is on purpose.
Is there any good reason why next-auth doesn't differentiate between signin or signup?

[chrisb2244]

With at least the EmailProvider, I can do the following:

import { signIn } from 'next-auth/react'

export const NewUserRegistration: React.FC<UserRegistrationProps> = (props) => {
const onSubmit: SubmitHandler<FormValues> = (data) => {
    void signIn<'email'>(
      'email',
      { redirect: false, email: data.Email },
      { signin_type: 'registration', registration_data: JSON.stringify(data) }
    )
....

and

export const UserSignIn: React.FC<SignInProps> = (props) => {
const onSubmit: SubmitHandler<SignInFormValues> = ({ email }) => {
    void signIn<'email'>(
      'email',
      { redirect: false, email: email },
      { signin_type: 'login' }
    )
....

then in [...nextAuth].ts,

const isRegistration = (req: NextApiRequest): boolean => {
  if (
    req.query.nextauth &&
    req.query.nextauth.length === 2 &&
    req.query.nextauth[0] === 'signin' &&
    req.query.nextauth[1] === 'email'
  ) {
    return req.query.signin_type === 'registration'
  }
  return false
}

.... 

callbacks: {
      signIn: async ({ user, email }) => {
        if (email.verificationRequest ?? false) {
          const exists = 'emailVerified' in user
          if (isRegistration(req)) {
            console.log(req.query.registration_data) // Data is found here
            console.log(`Returning ${!exists} because ${exists ? 'email exists' : 'email not found'}`)
            return !exists
          } else {
            if (exists) {
              console.log('Found email, logging in')
              return true
            } else {
              console.log('Email not found, blocking login')
              return false
            }
          }
        }
        return true
      }
    }

However, that doesn't help me get the 'registration_data' into the database :(
But it does allow you to handle them differently, at least a little.
Conceivably, I can try and implement some series of additional DB calls directly, in the style described here: #1069 (comment)

[martinatwainobicom]

Thanks for your help! I was missing ,that the request is actually available in the callbacks. In another use-case (sending localized emails) I've managed to get data to the backend by rewriting the request handler: #901 (reply in thread) Maybe this is of help for anybody.

[chrisb2244]

I've read your solution/comment there a few times (the key part of my "isRegistration" function was of course taken from there), so thanks!

Whilst considering doing the same I wondered if you had any issues with your caching and statefulness - did you need to do anything specific to ensure the cache remained available to the handler when the user returns (and retriggers the signIn callback)? I was slightly concerned that the handler (on the second time, after the user returns via the emailed link) might be unable to access the cache, depending on how it was stored.

It seems like a possible workaround is the one I linked to, storing in a separate table on first call (when I have access to the data and verificationRequest is true), and then retrieving and deleting on the second call (verificationRequest false, no access to the passed form data), but it still isn't really clear to me that I'll be able to do what I want (adjust the User model, adding fields and storing during registration) without editing NextAuth's code.

[martinatwainobicom]

You're totally right - caching is a an issue and I think the best way is to put the data into the database for later retrieval.

[isaac-svg]

I was going to ask the same question! I hope this feature is added soon.

[redimongo]

The reason there is no signup function is because you don’t need it if your using google or another provider. What you do is when you get the success login result you do a query to your user api to see if they are saved into your database. I have since moved to use logto, which works as more traditional login but oAuth (self hosted)Sent from my iPhoneOn 19 Oct 2023, at 03:05, isaac sakyi ***@***.***> wrote: I was going to ask the same question! I hope this feature is added soon. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[calebpitan]

Often times I forget what method I used to sign up on a website and I try credentials, email with a password, try the sign in with Google button, try Sign in with Apple button, etc.
The problem is, imagine I originally signed up with my Apple ID on the website, but because I couldn’t remember I tried first with Sign in with Google, and I implicitly got a new account created for me because there was no user with my Google email found, that would be terrible cause now I’ve inadvertently created multiple accounts on the same application.

This is one reason why the distinction between sign in and sign up is good and users shouldn’t be registered implicitly when they only intend to sign in, because their record wasn’t found.

The implementation on most apps usually have them distinct and I’ve used a few that don’t and implicitly create a new user on sign in.

Personal experience—it’s a bad UX.

[calebpitan]

I wrote an article on how to circumvent this downside that I think might help you separate sign-in intents from sign-ups.

Here’s the link: https://www.calebpitan.com/blog/handling-oauth-2-sign-in-and-sign-up-distinctly-with-next-auth.

I hope you find it helpful!

[tremby]

It looks like this link is dead. Is there a replacement location?

[pandanoir]

It looks like that page has been moved here.

https://dev.to/calebpitan/handling-oauth-2-sign-in-and-sign-up-distinctly-with-nextauthjs-8ic

[calebpitan]

I came here in 2025 to see if there's been a better solution, but instead I was able to modify the current solution, which also better adapts it to the RSC paradigm.

This is how I would do this in 2025:

import 'server-only'

import { type InitAuthOptions, initAuth } from '@hux/auth'

import { cookies } from 'next/headers'

import { NODE_ENV, SERVER_EMAIL_ADDRESS } from '@/lib/config/server'
import { database } from '@/lib/datasource'

const options: InitAuthOptions = {
  debug: NODE_ENV === 'development',
  email: { serverAddress: SERVER_EMAIL_ADDRESS },
  async getIntent() {
    const cookie = await cookies()
    const intent = cookie.get('auth.intent')?.value

    return intent === 'signin' || intent === 'signup' ? intent : undefined
  },
  pages: {
    signIn: '/signin',
  },
  sessionStrategy: 'jwt',
}

export const { handlers, signIn, signOut, ...apis } = initAuth(database, options)

middleware.ts

const AUTH_PATHS = new Set(['/signin', '/signup'])

export const middleware: NextMiddleware = (request: NextRequest) => {
  const response = NextResponse.next()

  // check if the page is a signin or signup page and include the correct auth intent in cookies
  if (AUTH_PATHS.has(request.nextUrl.pathname)) {
    response.cookies.set('auth.intent', request.nextUrl.pathname.replace(/^\//, ''))
  }

  return response
}

@hux/auth:

export function initAuth(session: Database, options: InitAuthOptions): NextAuthResult {
    ....
    callbacks: {
      async signIn({ user }) {
        const intent = await options.getIntent()

        if (!intent || intent === 'signup') {
          return true
        }

        const email = user.email

        if (!email) {
          return false
        }

       // this could be an api request doesn't have to be a direct database call
        const existingUser = await session.query.user.findFirst({
          where(fields, op) {
            return op.and(op.eq(fields.email, email), op.isNull(fields.deletedAt))
          },
        })

        if (!existingUser) {
          // you could return a url to the signin page with some query string that contains the error message,
          // grab it on the frontend, and display to your users just right on the sign in page still.
          return false
        }

        return true
      },
    },
}

[shayanrasoooli]

after 4 years of asking this question still there is no such a functiuon ....

[WesleyyRafaell]

where is the signup function?

[sreenathkumar]

As of my understanding, we want to sign up through Google, Facebook, or others but as we already signed up on Google, Facebook, or others there is no point in signing up again on our platform. As we're getting the user data from the provider then why we ask for it again? By using the providers we already know that the user is verified. So when user clicks on signin' that means we're assuming that the user is registered in our platform, if not we save the email and he becomes our registered user. If the email exists the user just enter into his account smoothly.

By this method, we just eliminate the hassle of registering.

[accustraswaraj]

It's not just about verification; you must also store the email and other details in the database to implement business logic effectively.

For example, imagine you have a table containing rows of data. If you want to display specific rows relevant to a particular user, you must store the user's email in the database. Without this, there would be no way to associate the data with the user, and as a result, everyone would have access to the entire table.

This is why saving user-specific details like email is crucial for implementing access control and ensuring a personalized experience.