Next-auth: When does any data get inserted into the session table ?

[ghoshnirmalya]

Your question
When a new user is created using Google provider, a new record gets inserted into both users and accounts tables. However, no new record gets inserted into the sessions table.

What are you trying to do
When a new user is created, a new record should be inserted into the sessions table as it is used for database sessions.

This is how I'm using next-auth in my application.

• [ ] Found the documentation helpful
• [ ] Found documentation but was incomplete
• [x] Could not find relevant documentation
• [ ] Found the example project helpful
• [ ] Did not find the example project helpful

[LoriKarikari]

I think the default is JWT but you can enable sessions as shown here.

[ghoshnirmalya]

@LoriKarikari Thank you. After making the following change in the [...nextauth].ts file made it work:

session: {
  jwt: false,
},

[iaincollins]

For completeness, I think probably we need a diagram to cover this as it's only possible to gleam this info from the schemas right now, but as a quick summary:

• Session table entries are only tied to User entries, not OAuth Provider Accounts (one User can have many Sessions).
• User entries in turn, can be tied to one or more OAuth Provider Accounts (one User can have many OAuth accounts, with any number of providers, including more than one account at the same provider).
• Session objects are small and discrete by design (for both efficiency and security).

NextAuth.js currently supports signing up and signing in with an OAuth provider, but it doesn't currently also provide OAuth Provider access (to do that as well, right now you would have to write that yourself).

This has come up enough that I've tried to address it in the v3 FAQ.

The reason we don't include OAuth providers in the session object as it bloat the payload for the session object and impact performance for users who have more than one OAuth Provider Account associated with their User entry, as we'd want to rotate each one that was stale before returning a response (token rotation isn't actually supported at all yet, but is is a consideration when we are keeping in mind - it's better to not expose the tokens at all in the API than to have them not be useable).

The good news is we have an open PR for exposing tokens (#425 by @tomvoss) so we might not be far off having a solution out of the box.

As @LoriKarikari says though, if you only need details for one provider, using JWT is a great way around this as you can choose exactly what you want in the JWT - specific to whatever your use case is - and from there expose it in the session. The v3 documentation for this is much better than the v2 docs.

(The default JWT payload in v3 is also different, but better! But the approaches in both are basically the same.)