OAuthAccountNotLinked for pre-existing users without account

[Gregoor]

This is probably as expected, so not a bug per-se, but it interferes with our apps needs. We want to create users before they have an account to email them a session-link (basically a JWT in the URL's query params, which gets put into the cookies on first load) usable for certain actions. While that flow works nicely, and they can then also claim that account by signing in, it fails when they try to sign-in without using the session-link we generated. We're getting an error from here:

next-auth/src/server/lib/callback-handler.js

Lines 204 to 213 in 86baefd

	if (userByEmail) {
	// We end up here when we don't have an account with the same [provider].id *BUT*
	// we do already have an account with the same email address as the one in the
	// OAuth profile the user has just tried to sign in with.
	//
	// We don't want to have two accounts with the same email address, and we don't
	// want to link them in case it's not safe to do so, so instead we prompt the user
	// to sign in via email to verify their identity and then link the accounts.
	throw new AccountNotLinkedError()
	}

In our best case that condition would not just check for the existence of a user by email, but also whether that user has an account. I think that also kind of aligns with the expectation formulated by the comment i.e.

BUT we do already have an account with the same email address

(which is not the case necessarily, as in our case we have a user without an account)

I'd be curious to hear any ideas around this! Thanks

[kcrtr]

Is there a specific reason you are not sending temporary passwords?

[Gregoor]

We'd want it to be as frictionless as clicking a link, though I guess we could also have that temp password in the URL and programmtically log-in with it. I will look into it, thanks for the pointer!

[balazsorban44]

I think you don't want to set passwords in query parameters.

[kcrtr]

I was more specifically thinking that you could send the temp password in an email.

[balazsorban44]

Check out the Email Provider https://next-auth.js.org/providers/email

You could use that for user signup, and after that provide the option to connect any account with the same email address.

[Gregoor]

I think what I'm failing to communicate effectively is that in the scenario which is not working for me the user does not have a session yet. And their only means of signing in/up is through an account which is not connected to a user yet, but a user for that email does already exist. So I basically want to automatically link accounts on sign-in, which from the FAQ I understand to be not supported currently.

However I think an important part of the exact solution hinges on if you want to limit access to the app to only user accounts you've created. Is that the case?

Not necessarily, there's both invited users and users who signed-up themselves in the system.

edit: Thinking about it some more, I think I ultimately just really need account linking, on sign-in, for oauth providers that I trust. So I guess best-case I could configure to be trusted, and have them be auto-linked (just like email is auto-trusted by default). Would you be open for PRs that enable auto-linking-on-signin-through-explicit-opt-in @balazsorban44 ?

[balazsorban44]

No, it is not supported to link accounts automatically without the user being logged in, and I don't see it being added at any time. As I haven't written that piece of code myself, let me link to the comments from the source code, which explains beautifully why it is not allowed:

next-auth/src/core/lib/callback-handler.ts

Lines 163 to 179 in ba39efb

	// If the user is not signed in and it looks like a new OAuth account then we
	// check there also isn't an user account already associated with the same
	// email address as the one in the OAuth profile.
	//
	// This step is often overlooked in OAuth implementations, but covers the following cases:
	//
	// 1. It makes it harder for someone to accidentally create two accounts.
	// e.g. by signin in with email, then again with an oauth account connected to the same email.
	// 2. It makes it harder to hijack a user account using a 3rd party OAuth account.
	// e.g. by creating an oauth account then changing the email address associated with it.
	//
	// It's quite common for services to automatically link accounts in this case, but it's
	// better practice to require the user to sign in *then* link accounts to be sure
	// someone is not exploiting a problem with a third party OAuth service.
	//
	// OAuth providers should require email address verification to prevent this, but in
	// practice that is not always the case; this helps protect against that.

[Gregoor]

Thanks, that does make sense to me in general. I think in our case, we would be open to relax it for certain providers, which we have a high degree of trust in, but I do appreciate the principled security view on it.

I am thinking now that thus I should probably just create these temporary-users without emails. Then people won't run into the AccountNotLinkedError and will be able to log-in. But it will not be the account that was created for them, so we will have to think about merging of users.

[Gregoor]

We've done some thinking and implementing and ended up just exposing a form on the error page for OAuthAccountNotLinked, which lets people send themselves a recovery-email (includes a link with a JWT in the URL, which gets put into the cookie, as mentioned in the first post).
Now it would be neat to have information about the account for which auth failed, to prefill the form with the user's email address. It looks like there is no event for errors during auth? Something like that would be very useful for us, e.g.:

NextAuth({
  ...,
  events: {
    async signUpError({ error, res, account }) {
      if (error.name == "OAuthAccountNotLinked") {
        res.writeHead(HttpStatus.FOUND, { Location: `/auth/error?error=OAuthAccountNotLinked&email=${account.email}` }).end();
      }
    }
  },
  ...
})

[Gregoor]

@balazsorban44 hope it's alright I ping you. I'm curious if adding an error event to next-auth, which includes the account for which it errord, would be an option? I'd be happy to send in a PR