Describe the bug
In your next-auth-example, default login screen (http://localhost:3000/api/auth/signin)
yarn && yarn add mongodb && yarn dev/api/auth/callback/twitter instead of redirecting back to the home screen, it goes to /api/auth/error?error=OAuthAccountNotLinked then /api/auth/signin?error=OAuthAccountNotLinked
I noticed that when I console.log in the signIn callback I still get the twitter data.

Am I missing something here or is this a bug? Because I'm getting the same issue in my personal app.
Documentation feedback
Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.
This is the error page displayed for the OAuthAccountNotLinked:

If you see OAuthAccountNotLinked it means you have already signed in with a different provider that is associated with the same email address.
Ah, but I only have signed in with Twitter. That's the only Provider I have with my app besides email AND I have only used this email via twitter oauth.

In fact I only have 1 account in my entire accounts collection, and that is the twitter signin for this user.
Btw, I don't have this problem in 2.2.0
I also wanted to say that I think this is a great library and I really appreciate all your hard work. 👏👏👏
I am not able to replicate this issue.
I can only suggest enabling debug: true option and seeing if your database connection is throwing any errors or unexpected behaviour.
added all these callback URLs to twitter since they changed:
http://localhost:3000/api/auth/callback/twitter
http://localhost:3000/auth/oauth/twitter/callback <- old docs said this (came up when I searched "twitter" on next-auth.js.og)
To confirm, the callback API has not changed between version 2 and version 3. The documentation for providers is correct: https://next-auth.js.org/configuration/providers#using-a-built-in-provider
The second callback URL format is for version 1 which was released in 2016-2017. At the top of the page it says "_WARNING This documentation is for version 1 which is no longer supported_."
^ Edit: It might be worth us removing the v1 one docs from the website if they are coming up in search results above more relevant results.
Btw, I don't have this problem in 2.2.0
Hmm that's interesting.
Can you replicate this issue with the example project?
PS: My suspicion here is that it might be a weird interaction with the Atlas Mongo instance. I no longer have an active mongo.net instance to hand to test it, but it would be worth identifying if the same issue be replicated with the example project. If it can it's probably related to the database connection in some way.
I will test the example project right now and report back
Thanks! If you do get the same issue, any information you can provide about the database / connection type (including example of the connection info, minus sensitive info) would be very helpful.
It works with 2.2.0 in the example.

My .env.local looks like
NEXTAUTH_URL=http://localhost:3000
SECRET=
AUTH0_ID=
AUTH0_SECRET=
AUTH0_DOMAIN=
FACEBOOK_ID=
FACEBOOK_SECRET=
GITHUB_ID=
GITHUB_SECRET=
GOOGLE_ID=
GOOGLE_SECRET=
TWITTER_ID=my-twitter-id
TWITTER_SECRET=my-twitter-secret
EMAIL_SERVER=smtp://username:[email protected]:587
EMAIL_FROM=NextAuth <[email protected]>
DATABASE_URL=mongodb+srv://username:[email protected]/database-name?retryWrites=true&w=majority&synchronize=true
I can't replicate an issue with the example project, using MongoDB and Twitter. I don't have any problems signing in, signing out and then back in again.
The example uses 3.x. Did you downgrade the version of it? Can you replicate the issue raise with the example project, running 3.x?
^ Sorry hit save prematurely (was on mobile).
Thinking about it, if it's just a test account I'd be included to drop those collections and just re-create it again (and use v3).
I have absolutely no idea what would be causing this. I've spun up a mongo.net service on Atlas and still can't replicate it.
I'll drop and try again. Yes, I downgraded and checked in yarn.lock to make sure it was 2.2.0.
You were correct. It was the DB. Weird... So sorry I drug you through all this. I should've tried that from the get go.
I also tried your example with a fresh DB and it worked. Didn't try a new collection within the same db, but I'd assume it would work with one.
Hi @iaincollins I just found the same error when testing oauth with Google and Github. I'm wondering is there a way to connect both providers to the same user instead of rejecting it? So sign in with Google and sign in with Github will go to the same user account.
I got the same error if both facebook and google has the same email. It's better to provide option to merge user.
@fzxu I've been tinkering with this since yesterday. Until the library handles the merge, I think you need to handle the sign-in process yourself
I've tried writing the SignIn callback configurations, but it seems to be called after the DB operation is resolved.
The next option is updating the next-auth.functions.js to see if it works.
@nsebhastian @fzxu
Please feel free to open a new issue if you have a question about why something works a particular way.
This has come up before so I've raised a PR which addresses it in the FAQ:
Automatic account linking on sign in is not secure between arbitrary providers - with the exception of allowing users to sign in via an email addresses as a fallback (as they must verify their email address as part of the flow).
When an email address is associated with an OAuth account it does not necessarily mean that it has been verified as belonging to account holder — how email address verification is handled is not part of the OAuth specification and varies between providers (e.g. some do not verify first, some do verify first, others return metadata indiciating the verification status).
With automatic account linking on sign in, this can be exploited by bad actors to hijack accounts by creating an OAuth account associated with the email address of another user.
For this reason it is not secure to automatically link accounts between abitrary providers on sign in, which is why this feature is generally not provided by authentication service and is not provided by NextAuth.js.
Automatic acccount linking is seen on some sites, sometimes insecurely. It can be technically possible to do automatic account linking securely if you trust all the providers involved to ensure they have securely verified the email address associated with the account, but requires placing trust (and transfering the risk) to those providers to handle the process securely.
Examples of scenarios where this is secure include with an OAuth provider you control (e.g. that only authorizes users internal to your organization) or with a provider you explicitly trust to have verified the users email address.
Automatic account linking is not a planned feature of NextAuth.js, however there is scope to improve the user experience of account linking and of handling this flow, in a secure way. Typically this involves providing a fallback option to sign in via email, which is already possible (and recommended), but the current implementation of this flow could be improved on.
Providing support for secure account linking and unlinking of additional providers - which can only be done if a user is already signed in already - was origionally a feature in v1.x but has not been present since v2.0, is planned to return in a future release.
You were correct. It was the DB. Weird... So sorry I drug you through all this. I should've tried that from the get go.
I also tried your example with a fresh DB and it worked. Didn't try a new collection within the same db, but I'd assume it would work with one.
This also worked for me. Thanks so much everyone!
Most helpful comment
You were correct. It was the DB. Weird... So sorry I drug you through all this. I should've tried that from the get go.
I also tried your example with a fresh DB and it worked. Didn't try a new collection within the same db, but I'd assume it would work with one.