one user, multiple account providers

[tanshunyuan]

Hi guys, do you think it is possible to mimic OAuth account linking with nextauth?

[balazsorban44]

#1002 (comment) might be relevant. I will try to discuss this with @iaincollins when we get the time! Thanks for your suggestion.

[balazsorban44]

I understand! Unfortunately, I haven't succeeded in contacting Iain yet, and I don't have enough expertise to give a good opinion on the matter. Hopefully, when he gets back to the project, he will have a look at this as well!

It is awesome to hear that you could consider funding, I set up a sponsor profile on the homepage if you are interested: https://github.com/nextauthjs/next-auth

I do work on next-auth in my free time, and up until now have managed/maintained most of the project alone for a few months now. Every contribution is welcome! (@lluia has been of great help 🙏 in migrating the types from DefinitelyTyped, and he is considering helping out more with the repo in general, which is a bit of relief, and fantastic news for next-auth's future!)

You could also consider opening an issue about this topic, but I wouldn't recommend creating a PR just yet, because there have been other PRs before, and Iain closed them down. The most reasonable thing to do would be if we got an issue, for now, I think and hope that Iain comes back soon. 🙂

[tanshunyuan]

I apologies if this sounds rude and it being out of topic but what is the point of having multiple login providers when the accounts can't be linked. Is the purpose for having multiple login providers to allow users to authenticate with only one login provider and when they try to use other login provider listed on a login page they are rejected.

Eg. A website allows login/registration via google or github, if they choose to login with google they can no longer choose to login with github because they initially authenticated with google?

[lovegrovegeorge]

I understand! Unfortunately, I haven't succeeded in contacting Iain yet, and I don't have enough expertise to give a good opinion on the matter. Hopefully, when he gets back to the project, he will have a look at this as well!

I reached out to Iain's email but no luck so far. Would definitely be ideal to get his opinion as he has the right experience by what I can see

It is awesome to hear that you could consider funding, I set up a sponsor profile on the homepage if you are interested: https://github.com/nextauthjs/next-auth

I'm personally not a fan of another subscription as a form of sponsoring but I do really see the problem with funding open source. Once value has been proven I like the idea of new feature requests being separate funded projects. People can vote with their wallets for what gets prioritised - the most valuable thing will bubble to the top and help compound the usefulness to the users. I think incentives driven development should help create more funding overall (e.g. I know you can improve this project, I will pledge X amount for you to work on Y feature that benefits me). I'd contribute $100 towards a good implementation of the account linking, if you made a funding proposal somewhere for people send me a link. Would be good if it was a threshold one where funds aren't taken unless the work is going to be done so its action driven funding. Still good to have a one time donate option as well of course.

[balazsorban44]

At the end of the day, currently I don't seek to have an actual income from this project, I just enjoy working on it, and chose to let express others if they enjoy me working on it as well as. Setting up anything else would feel an overcomplication, which I don't want right now, and we haven't even discussed this topic deeply with Iain. This is a topic for another discussion anyway.

As said, you could certainly open an issue and hope that others are interested and will get upvoted. You don't even have to fund it. 😊

@tanshunyuan I unfortunately don't have an answer, as I haven't been around when Iain has created the account linking functionality, so I don't understand his goals and reasons fully just yet, and I haven't been able to contact him. When he gets back, I'm sure we will discuss this topic.

[lovegrovegeorge]

@balazsorban44 was just my 2 cents! The input of a team behind well used quality open source code should be compensated for their work. Good incentives would help drive more people to improve the projects they use and also create other projects with the knowledge it is a safe path to make a living. Hopefully we find a way to move towards ensuring public goods are compensated better in the future. Thanks for everything either way!

[ramiel]

Is there any news about this @balazsorban44 ? It's clear, from this and other issues/discussions/PR, that having the ability to link accounts is a demanded feature that got no answer since more than one year. Is there any plan about this that you can share?
I understand the rationale behind this is that we cannot trust oauth account about the email they provide, but at the same time we should be able to decide to trust some of those providers. To be honest I also think we should be able to take the risk and decide to always trust automatic linking, but I understand if the library doesn't want to expose such behavior.

[matbee-eth]

Would also be interested as I'm using Two login methods: One Social, and one with Crypto wallet. - and logging in to one/other seems to wipe session between the two logins.

[NathanLandsX]

I have the same use case. Currently using Auth0, would love to switch to Next Auth.

[nfts2me]

Did you find a way to solve this?

[matbee-eth]

Did you find a way to solve this?

No I didnt

[lobatolais]

It would be awesome to have this feature added to next-auth!

[nimeshvaghasiya]

@lobatolais I just found your repo next-social-login.
and tried to check on next-social-login.vercel.app for "one user, multiple provider", unfortunately fb provider not working. just would like to know either it support one use multiple provider or not?

[flosrn]

Any news about this potential feature? Or has someone found a workaround?

[ephraimduncan]

@balazsorban44

[zephimir]

Oh yes please this would be awesome for users

[nbouvrette]

Just in case this helps anyone, the allowDangerousEmailAccountLinking: true is available (not sure since when exactly) but I'm not sure how much you can customize the account linking functionality yet. For example, if you want to link different providers on an existing account and your providers have different email addresses, I'm not sure if this is feasible at this stage.

[nimeshvaghasiya]

would like to link different providers on an existing account but having same email address for all provider. so that end user can login with google, discord etc..

[nbouvrette]

Yes, if you use allowDangerousEmailAccountLinking: true you can link providers on the same account by creating a UI to link other providers. All you need to do is create links that will call the signIn next-auth API while logged in to providers that are not linked to the account.

[rexfordessilfie]

@tanshunyuan I ran into this issue recently which led me here, and I managed to implement a similar solution for an app I am working on where I needed a user to be able to login with a Web3 wallet, and then subsequently link other accounts such as Spotify to their profile.

The solution is rather long, but the key insights are:

1. Wrapping the NextAuth handler one level deeper to get access to the req and res objects, and then
2. Getting access to the currently signed in user inside of the signIn callback (or very carefully inside the jwt callback) with a call to getSession.
3. Once we know who the currently logged in user is, we can treat the signIn flow as a request to link a new account. If we are doing this in the signIn callback, we could return a url such as '/profile' to redirect the user back to their profile page with some notification of success.

Here are some caveats with the process above for my situation:
For me, this entire process uses a database for persisting some single user account with a unique id to which all additional accounts a linked to.
This way, I can do things such as:

1. Preventing a provider account from being linked to more than one user account accross the entire application
2. Allow logins only through a single primary provider (a Web3 wallet), and having the others like Spotify, only be for verification purposes to get access to extra features within the application.
   If you don't have such needs, then maybe the state (of all connected provider accounts) could also be managed inside the JWT token itself.

Another piece of the solution is to make sure to:

1. Update token.user appropriately in the jwt callback so that it always contains that unique user id from our database to which we link all accounts,
2. Set that same user id within the session object in the session callback, so that our call to getSession mentioned above, gives us back the unique id for determining who the currently logged in user is
3. With these two in place, we know where to link additional accounts to in our database when we receive the request to

Lastly, I want to question one assumption in the logic of this process:

1. If a user is already signed in, is the next signin attempt truly an attempt to connect an account?
   • If you can make this assumption, then the above process should work perfectly!
   • Otherwise, you may need to add some strategies on top of the process to make sure that it is truly a request to link an account vs. a mistake of two different people using the same computer for example.
   • I am not sure if this is possible, but if next-auth provided a way to pass some data through in the signIn call on the client, we could do that there for example, and only pass that data through from a button on the UI that clearly says link additional account.
   • But if it doesn't, you could also have a two-step process such as having to click a link in an email to complete the process, such as with email-verification or password-reset process to make sure of the user's intent.

If anyone would like to see a generalized POC/example application for this with some of the functionality mentioned above, reach out and I could build one/pair in building one with someone else. But otherwise, it would also be lovely to see some built-in NextAuth primitives for performing this use-case of one user account with multiple providers.

[rexfordessilfie]

Hi @angelagilhotra, I like the sound of that. It would be helpful to have such a template to use until it is hopefully supported by Next-Auth. I have a private repo with a crude version of this working at the moment. Shall I pull it out into a fresh repo and then we work from there? Let's connect via email/twitter/discord so we could collaborate easier!

[anggxyz]

@rexfordessilfie sounds good! sending you an email

[rexfordessilfie]

Hi all, I have put together this repo with this functionality extracted from my working solution and implemented with some improvements to be a more generalizable solution.

Link: https://github.com/rexfordessilfie/next-auth-account-linking

Some extra notes:

• NextAuth v4: The implementation uses NextAuth's v4 getServerSession over older getSession in my original implementation, which for this implementation, requires defining the authOptions dynamically as function that can receive the req object from the request. This req object is needed for the signIn callback to detect that there is a user already logged in and do the linking!
• Next.js App Directory: I considered implementing this with the new App Router approach, but opted out of this as I imagine the OP and others might still be using Pages directory. I may move it to App Router as an exercise but maintain an older branch with the Pages directory implementation.

Hope this helps! There might still be significant testing and tweaking to make it fit other application use-cases, but the underlying idea/approach might be similar. If you follow this approach or similar, please raise an issue/comment on challenges faced/tweaks made for the benefit of any one else wanting to implement this as well!

[rexfordessilfie]

For anyone interested, here is some more discussion on security concerns and edge cases: #2808

[sowee15]

I was doing something similar, it works well, but I found out that it doesn't work if trying to connec to the Apple provider: the current session will always be null in the signIn callback for some reason.

[Tasin5541]

Just faced the same issue. Would be great if this feature gets added. Or at least an option to return to the login screen with a callback, so we can customize the error message.

[nbouvrette]

You can do this by setting a callback API like this:

pages: {
    signIn: '/api/auth-callback/sign-in',
    signOut: '/api/auth-callback/sign-out',
    error: '/api/auth-callback/error',
    verifyRequest: '/api/auth-callback/verify-request',
    newUser: '/api/auth-callback/new-user',
  },

Then your callback API has to pass the error as an argument to the login page.

It's a convoluted solution and I think that if next-auth would have focused on providing APIs for custom login pages rather than trying to provide their own, the solution would have been a lot simpler.

[borgbob]

This is currently possible by using the JWT callback and parsing the current session cookie. Here's how I do it in an app which allows login via credentials and then link other social accounts:

async jwt({ token, user, trigger, account, profile }) {
      if (trigger !== 'signIn' || !user) {
        return token
      }

      if (account?.provider === 'credentials') {
        // logging in with credentials
        return token
      }

      const provider = account?.provider
      if (!provider) {
        return token
      }

      const sessionCookie = cookies().get("authjs.session-token")?.value
      if (!sessionCookie) {
        console.warn('No session cookie found')
        return token
      }

      const secret = process.env.AUTH_SECRET
      // the "verify" function will decrypt/verify the session cookie
      const currentJwt = await verify(secret, sessionCookie)

      const linkedAccounts = (currentJwt.linkedAccounts ?? {}) as Record<string, string>
      switch (provider) {
        case 'github':
          linkedAccounts[provider] = profile?.login as string
          break;
        case 'twitter':
          linkedAccounts[provider] = (profile?.data as any)?.username as string
          break;
        default:
          console.warn('Unknown provider', provider, profile)
          break;
      }

      return {
        ...currentJwt,
        linkedAccounts
      }
    }

I've put a proposal on how this can be simplified with a small change to jwt callback API: #10785

[gilesbradshaw]

You can link as many user accounts together as you like using multiple sessions. This example links two together https://next-auth-nextjs-git-multi-sessions-demo-gilesbs-projects.vercel.app/ however the next-auth package doesn’t support this client side due to the __NEXTAUTH global variable. Imo this should be removed and the react components changed so they support multiple sessions. (That’s what I did for this example) I’m not sure what the argument is for the global __NEXTAUTH variable. I’m just using the password provider from the example app in this example but it works fine with Facebook, google etc. so you can link Facebook accounts together or Facebook with google etc. all you need is multiple session cookies and you have multiple simultaneous sign ins.

[gilesbradshaw]

Personally I think it’s a massive downside of the next with client library that it doesn’t support this out of the box. If it supports multiple simultaneous logins it will also support just one so I can’t see the case for it not doing so. Lots of apps need multiple sign ins. For example zapier style apps. Also linking accounts based on common emails is restrictive. Why shouldn’t an app link accounts with different emails? For example linking two google accounts.