This project is great - thank you for the hard work. I couldn't find how to do what I want in the docs (and that may even be a non-goal for this project) so I'm asking that here.
Your question
My app needs the ability to have several accounts for a given user. A user should be able to login into 2+ Google accounts (with different emails). Do we have the ability to do that today (it looks like the DB schema could support this)? If not, is this feature something that could/will be part of this project?
Documentation feedback
Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.
Hi there! This is a good question.
This is explicitly supported in the schema and internally but it's not yet an advertised feature as it's not quite finished.
Basically, if you sign in, then go to the sign in page AGAIN while already signed in, and this time sign in with a different account (even two accounts with the same provider, such as two different Google accounts) you will see both accounts are linked back to the same user and either can be used to sign in on another computer.
(The details from the first account they use are what gets stored as their name / email / image in the user table.)
The reason it's not advertised yet as this is I think account management is the only aspect where there is not yet feature parity with v1. What is missing are API routes for linking and unliking OAuth accounts (and for deleting user accounts all together). There are also some considerations for the email sign in / recover flow when this is supported.
The current behaviour of the sign in page when already signed in will likely change at some point, once these API endpoints are added (e.g. to display page users can use to link/unlink accounts instead).
Hey - thank you for your answer, it sounds good.
However while logged I've tried logging in again (I've added a new Add an account link to /api/auth/signin to my app) and this ended up creating a second user and a second account. Any idea what I could be doing wrong? Feel free also to point to the logic that handle that case, I'm happy to spend some time debugging the issue.
Did some debugging and discovered that it only works when sessions are stored on the DB (jwt: false). Not sure if that is intended.
@gip Thank you for looking into that!
That's not intended and I wasn't aware it was happening (I haven't checked to verify I see that, but I can believe it!).
There is some divergence in what is supported in the Database Session and JWT Session flows (e.g. what providers are supported) and have been thinking about if / how / when to address that.
If you don't mind it's helpful to have this issue open as a reminder to address that specifically in an enhancement and to close it once it's at least been captured with a suggestion about how we might want to handle it in future.
Sounds goods!
+1 for getting this to work with JWT!
Most helpful comment
Did some debugging and discovered that it only works when sessions are stored on the DB (
jwt: false). Not sure if that is intended.