Credentials provider with Database strategy

[nodimhu]

Hi community!

I'm trying to set up Credentials provider alongside Nodemailer and Google providers with database strategy. Both Nodemailer and Google work out of the box, but I understand that Credentials provider needs some extra work. According to the documentation:

"By default, the Credentials provider does not persist data in the database. However, you can still create and save any data in your database, you just have to provide the necessary logic, eg. to encrypt passwords, add rate-limiting, add password reset functionality, etc."

So, I'm assuming it should be doable. I'm setting up the provider:

const providers = [
  Credentials({
    credentials: {
      email: {
        label: "Email",
        placeholder: "[email protected]",
      },
      password: {
        label: "Password",
        type: "password",
      },
    },
    async authorize(credentials): Promise<User | null> {
      if (
        !credentials ||
        !credentials.email ||
        !credentials.password ||
        typeof credentials.email !== "string" ||
        typeof credentials.password !== "string"
      ) {
        return null;
      }
  
      return await verifyCredentials(
        credentials.email,
        credentials.password,
      );  // this returns a User if authorized, otherwise null
    },
  }),
  // Nodemailer and Google ommited...
]

Creating the session seems straight-forward enough, I'm just creating it in the signIn callback like so:

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers,
  callbacks: {
    async signIn({ user, account }) {
      if (user?.id && account?.provider === "credentials") {
        await adapter.createSession({
          sessionToken: crypto.randomUUID(),
          userId: user.id,
          expires: new Date(Date.now() + 60 * 60 * 24 * 30 * 1000),
        });
      }
      return true;
    }  
  },
  session: {
    strategy: "database",
  }.
  // secret, adapter, etc...
});

So far so good, the sign-in flow works and the user is authorized.

However what I'm seeing is that the Credetials provider creates a JWT token in parallel and also sets it in the cookie, so getSession can never work. It feels that it wants to use the jwt strategy.

I found this blog post in an old discussion about this topic (#4394), in which the author describes a way to make this work, but it feels way too fragile, and according to the documentation, there should be a means to do this properly.

What do you think? Am I missing something or is this indeed a bug or as-of-yet-missing-feature?

--
Zsolt