I am getting this error. Any ideas?

Not sure how to get around that. Maybe there's a way to disable that error?

[next-auth][error][CALLBACK_CREDENTIALS_JWT_ERROR]
https://next-auth.js.org/errors#callback_credentials_jwt_error Signin in with credentials only supported if JWT strategy is enabled UnsupportedStrategy [UnsupportedStrategyError]: Signin in with credentials only supported if JWT strategy is enabled

@AaronMBMorse

That is because you're not using JWT strategy in nextAuth options
Check this out. You have to use strategy: JWT rather than database so that you can use credentials login

Thank you @Ahmadh26. I saw that when I was looking through the docs.

Isn't the objective of what @nneko wrote to have credentials with the database strategy?

If you set the strategy to jwt and have a adapter does it store the session data in the database? Assuming it does, can you sign someone out before the jwt token expires?

The project requires the ability to end sessions on the server so we can't use normal jwt. There needs to be something stored server side that gets check to make sure some permissions haven't changed.

@AaronMBMorse yes the patch above works and is intended for you to use with a "database" strategy. However, you haven't shared enough details for how you have nextauth setup for me to provide any help. The **session** property in the nextauth options should look something like the below:

session: {
    strategy: "database", // Store sessions in the database and store a sessionToken in the cookie for lookups
    jwt: false,
    maxAge: 30 * 24 * 60 * 60, // 30 days to session expiry
    updateAge: 24 * 60 * 60, // 24 hours to update session data into database
}

@nneko here is my next auth file with the additions you recommended.

Right now when I send a post request to /api/auth/signin I am getting the error that says I have to use jwt for credentials.

[next-auth][error][CALLBACK_CREDENTIALS_JWT_ERROR]

`
import NextAuth, { NextAuthOptions } from 'next-auth'
import type { NextApiRequest, NextApiResponse } from 'next'

// Config
import { DATABASE_URL, SESSION_SECRET } from '@config'

// Utils
import { SnakeNamingStrategy } from 'typeorm-naming-strategies'

// Adapter
import { TypeORMLegacyAdapter } from '@next-auth/typeorm-legacy-adapter'

// Providers
import CredentialsProvider from 'next-auth/providers/credentials'

// Entities
import { AppDataSource } from '@data-source'
import { User } from '@Entities'

import { randomUUID } from 'crypto'
import Cookies from 'cookies'
import { encode, decode } from 'next-auth/jwt'
import { Provider } from 'next-auth/providers'

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
const generateSessionToken = () => {
return randomUUID()
}

const fromDate = (time: number, date = Date.now()) => {
return new Date(date + time * 1000)
}

const adapter = TypeORMLegacyAdapter({
type: 'postgres',
url: DATABASE_URL,
synchronize: false, // DO NOT CHANGE ME (Can Delete Entire DB)
namingStrategy: new SnakeNamingStrategy()
})

const providers: Provider[] = [
CredentialsProvider({
name: 'credentials',
credentials: {
email: {
label: 'Email',
type: 'email',
placeholder: 'testing@gmail.com'
},
password: {
label: 'Password',
type: 'password'
}
},
authorize: async credentials => {
try {
const { email, password } = credentials as { email: string; password: string }

      // Fail if there is missing credentials
      if (!email || !password) {
        return null
      }

      // Initialize data source
      if (!AppDataSource.isInitialized) {
        await AppDataSource.initialize()
      }
      const userRepo = AppDataSource.getRepository(User)

      // Try to find a user
      const user = await userRepo.findOne({ where: { email } })

      if (user) {
        console.log('Authorization success')

        return {
          id: user.id,
          name: 'first last'
        }
      }

      // Failed to find user
      return null
    } catch (e) {
      console.log('Authorization error: ', e)
      return null
    }
  }
})

]

const authOptions: NextAuthOptions = {
adapter,
providers,
secret: SESSION_SECRET,
session: {
strategy: 'database',
maxAge: 30 * 24 * 60 * 60, // 30 Days
updateAge: 24 * 60 * 60 // 1 Day
},
callbacks: {
jwt: async ({ token, user }) => {
if (user) {
token.id = user.id
}
return token
},
session: async ({ session, token }) => {
if (token) {
session.id = token.id
}
return session
},
signIn: async ({ user, account, profile, email, credentials }) => {
if (req.query.nextauth!.includes('callback') && req.query.nextauth!.includes('credentials') && req.method === 'POST') {
if (user) {
const sessionToken = generateSessionToken()
const sessionMaxAge = 60 * 60 * 24 * 30 // 30 Days
const sessionExpiry = fromDate(sessionMaxAge)

        await adapter.createSession({
          sessionToken: sessionToken,
          userId: user.id,
          expires: sessionExpiry
        })

        const cookies = new Cookies(req, res)

        cookies.set('next-auth.session-token', sessionToken, {
          expires: sessionExpiry
        })
      }
    }
    return true
  }
},
jwt: {
  encode: async ({ token, secret, maxAge }) => {
    if (req.query.nextauth!.includes('callback') && req.query.nextauth!.includes('credentials') && req.method === 'POST') {
      const cookies = new Cookies(req, res)
      const cookie = cookies.get('next-auth.session-token')

      if (cookie) return cookie
      else return ''
    }
    // Revert to default behaviour when not in the credentials provider callback flow
    return encode({ token, secret, maxAge })
  },
  decode: async ({ token, secret }) => {
    if (req.query.nextauth!.includes('callback') && req.query.nextauth!.includes('credentials') && req.method === 'POST') {
      return null
    }

    // Revert to default behaviour when not in the credentials provider callback flow
    return decode({ token, secret })
  }
},
pages: {
  signIn: '/signin'
},
debug: true

}

return await NextAuth(req, res, authOptions)
}
`

@AaronMBMorse Hey! Really appreciate you diving into why server-side is the go-to for hashing passwords. It’s super insightful and definitely highlights some key points about security and keeping things smooth for users. 🛡️

But, you know, I've been turning a thought around in my head. While I totally get where you're coming from, there's this one thing that keeps nagging me. When we only hash passwords on the server-side, there's this sneaky risk of plaintext passwords getting a bit too cozy with the server environment. Imagine, just for a sec, that they end up in logs, memory dumps, or—knock on wood—the server gets compromised right before the hashing magic happens. It's kinda spooky thinking that even the most well-meaning server admins might accidentally get a peek at those passwords. And let's not even start on the external breach boogeyman. 😱

So, here's a thought: What if we mix it up and do a bit of both? Like a security layer cake!

First Layer - Client-Side Hash: We start with hashing the password on the user's side. It's like putting a disguise on the password before it even leaves the house. That way, the real password never has to take that risky trip over the internet in its birthday suit.

Second Layer - Server-Side Magic: Once our disguised password arrives at the server, we go for round two of hashing (and don’t forget the salt!). It's like adding another layer of disguise, so even if someone gets their hands on it, they’re miles away from the real deal.

I’m thinking this could be our secret sauce to keep things extra secure without making it a hassle. It's like having both a belt and suspenders—why not, right?

Keen to hear what you think! Could this be our middle ground, or is there a plot twist I’m missing?

@shtse8 In this scenario, you have two options:

• In my approach, I use the full-stack framework Nuxt 3. This allows me to manage data transactions internally within the framework, avoiding external network requests. I can securely handle credentials, validate, salt, hash, and store data in the database without it ever leaving the confines of the full-stack application.
• Alternatively, you can utilize tools such as Uncrypto, which offers a unified, platform-agnostic cryptographic interface. With this option, you can encrypt user data on the client-side before sending it to the backend. Upon receipt, the data can be decrypted, validated, and processed accordingly. It's essential to employ additional tools like Infiscal to manage sensitive information such as cryptographic keys securely.

Regarding the concern about data ending up in logs, memory dumps, or other unintended locations, I lack significant experience in those specific scenarios to offer the best approach for handling them effectively.

Furthermore, when considering hashing passwords on the client and then again on the server, it's crucial to note that certain hashing algorithms may not handle nested hashing efficiently. There have been issues reported with some algorithms (I don't recall whether it was bcrypt, scrypt, or argon2), encountering problems with nested hashing, potentially leading to password integrity issues.

However, as the saying goes, "the strength of a chain is limited to that of the weakest link." This underscores the importance of not only employing robust cryptographic measures but also ensuring the security of the overall environment. Factors such as poorly handled keys or the presence of malicious actors within your development team can compromise the effectiveness of even the most stringent cryptographic practices.

In essence, it ultimately aligns with the guidance provided in the auth.js documentation, which intentionally restricts the functionality for credentials-based authentication. This limitation serves to discourage reliance on passwords due to their inherent security risks and the added complexity associated with supporting usernames and passwords.

Thank you for sharing your insights into working with security using Nuxt 3 and other tools like Uncrypto and Infiscal. It's clear that you have a solid understanding of the complexities of data security and encryption, which is really reassuring.

I share your sentiments about using Nuxt 3 and Auth to create a seamless development experience while maintaining strong security. That’s what we’re all striving for, right? The perfect balance between development efficiency and robust security measures.

What you mentioned about the potential pitfalls of relying solely on password credentials resonates very much with me. This is a complex issue and one that really should be moving away from traditional password-based authentication. The way you manage data transactions within the framework to minimize external vulnerabilities is very clever.

I've been thinking a lot about my past practices, specifically hashing passwords in Vue component scripts before sending them to API endpoints. My original intention for doing this was to add an extra layer of security from the user side. However, your insights have made me rethink and evaluate the effectiveness and potential risks of this approach.

Thinking about sending passwords, potentially reused in critical services like banking or mail, directly to the server does raise significant trust issues. This is a real problem faced by many users, who knowingly or unknowingly risk their security due to password reuse. This is why I prefer a client-side hashing approach - at least ensuring that the original password is not exposed directly during transmission or server processing.

What you mention about the challenges of handling nested hashes, and the specific algorithms that may not be well suited to handling it, are particularly illuminating. This is a reminder of the delicate balance we need to maintain when applying security measures to ensure they don’t inadvertently weaken the system.

Adopting a Zero Trust philosophy seems more relevant than ever, not only in the way we design systems, but also in how we handle the trust dynamics between service providers and users. Your discussion definitely inspired a lot of thinking on my part about how to better balance these considerations in my work.

Thanks so much for this exchange, @ArthurSegato . This was really informative and thought provoking. Look forward to more discussions like this and exploring how we can continue to keep user trust and security top of mind while protecting our apps.

It was really a pleasure to communicate!

Hi @shtse8, I know this is an old topic but it might be useful for other readers. The purpose of hashing the password server-side is to prevent the instance in which the database itself gets compromised one cannot then use the retrieved hashed password to login to someone's account. As you can imagine, if one were to retrieve the hashed password from the database and then try and login to someone's account, they would send the hashed password to the server which would then get hashed again and wouldn't evaluate to the same value stored in the database. If the password is hashed client side then the server would be storing, from its perspective, a plain text password. If a malicious user were to then acquire that password from the database they could simply bypass the hashing function clientside and send the hashed password directly and get acces to the account. You already mentioned that we could hash the password on both sides which is a solution but in my opinion it is unnecessary security. I understand your concern would be that the password could get logged but that is something that should never happen and if it did then the company would be liable.

Hopefully that explains the purpose of hashing server-side. Hashing clientside defeats the purpose, hashing serverside is the intended purpose, hashing both sides is feasible but imo unnecessary.

Hi @OllyMan21 ,

Thank you for your detailed explanation. I understand your perspective on hashing passwords server-side. The reasoning you provided makes sense, particularly in the context of preventing attackers from using stolen hashed passwords to access accounts. Hashing client-side indeed wouldn't offer the same level of protection since the hashed password could be used directly if intercepted.

However, there is a different cultural perspective to consider, particularly in regions where there's a significant mistrust of servers and companies handling sensitive information. This is especially true in Chinese culture, where people are more cautious about potential data breaches and the misuse of their passwords.

Many users tend to reuse passwords across multiple sites and services. If their passwords are sent to the server without any encryption, there's a fear that the company could potentially misuse these passwords to access other accounts, such as personal email accounts. This concern leads to a lack of trust in websites that do not encrypt passwords before sending them to the server, with such sites often being seen as fraudulent or phishing attempts.

Given these concerns, it’s common for people here to prefer client-side hashing before sending passwords to the server, even if it might be perceived as unnecessary security from a technical standpoint.

I hope this provides some insight into the cultural differences and the reasons behind the preference for client-side hashing in some regions.

Best regards,
Kyle

thank you @abehidek.
Yours seems very similar to mine:

import type { NextApiRequest, NextApiResponse } from "next"
import NextAuth from "next-auth"
import type { NextAuthOptions, SessionOptions } from "next-auth"
import type { Adapter } from "next-auth/adapters"
import { encode, decode } from "next-auth/jwt"
import CredentialsProvider from "next-auth/providers/credentials"
import GoogleProvider from "next-auth/providers/google"
import { PrismaAdapter } from "@next-auth/prisma-adapter"
import type { User } from "@prisma/client"
import bcrypt from "bcryptjs"
import Cookies from "cookies"
import { randomUUID } from "crypto"

import { env } from "@/env/server"
import { prisma } from "@/server/prisma"
import { parseTenantDomain } from "@/utils/routes"

const getAdapter = (req: NextApiRequest, res: NextApiResponse): Adapter => ({
  ...PrismaAdapter(prisma),
  async getSessionAndUser(sessionToken) {
    console.log("PRE SESSION", sessionToken)
    const tenant =
      (req.query.tenant as string) ?? parseTenantDomain(req.headers.referer ?? req.url!)
    const userAndSession = await prisma.session.findUnique({
      where: { sessionToken },
      include: {
        user: {
          select: {
            id: true,
            email: true,
            name: true,
            image: true,
            agencies: {
              where: {
                agency: {
                  domain: tenant ?? "",
                },
              },
              select: {
                agency: {
                  select: {
                    domain: true,
                  },
                },
                role: true,
              },
            },
          },
        },
      },
    })
    console.log("SESSION USER", sessionToken, userAndSession)
    if (!userAndSession) return null

    const role = userAndSession.user.agencies.find(a => a.agency.domain === tenant)?.role

    const { user, ...session } = userAndSession
    const userWithRole: any = { ...user, role }
    return { user: userWithRole, session }
  },
})

const session: Partial<SessionOptions> = {
  strategy: "database",
  maxAge: 30 * 24 * 60 * 60, // 30 days
  updateAge: 24 * 60 * 60, // 24 hours
}

export const authOptions = (req: NextApiRequest, res: NextApiResponse): NextAuthOptions => {
  const adapter = getAdapter(req, res)
  return {
    callbacks: {
      session({ session, user }) {
        console.log("SESSION", session, user)
        if (session.user) {
          session.user.id = user.id
          session.user.role = user.role as string
        }
        return session
      },
      async signIn({ user }) {
        if (
          req.query.nextauth?.includes("callback") &&
          req.query.nextauth?.includes("credentials") &&
          req.method === "POST"
        ) {
          if (user && "id" in user) {
            const sessionToken = randomUUID()
            const sessionExpiry = new Date(Date.now() + session.maxAge! * 1000)
            const forwarded = req.headers["x-forwarded-for"] as string
            const ip = forwarded ? forwarded.split(/, /)[0] : req.connection.remoteAddress

            await adapter.createSession({
              sessionToken,
              userId: user.id,
              expires: sessionExpiry,
              userAgent: req.headers["user-agent"] ?? null,
              ip,
            } as any)

            const cookies = new Cookies(req, res)
            cookies.set("next-auth.session-token", sessionToken, {
              expires: sessionExpiry,
            })
          }
        }

        return true
      },
    },
    jwt: {
      encode(params) {
        if (
          req.query.nextauth?.includes("callback") &&
          req.query.nextauth?.includes("credentials") &&
          req.method === "POST"
        ) {
          const cookies = new Cookies(req, res)
          const cookie = cookies.get("next-auth.session-token")

          if (cookie) return cookie
          else return ""
        }
        // Revert to default behaviour when not in the credentials provider callback flow
        return encode(params)
      },
      async decode(params) {
        if (
          req.query.nextauth?.includes("callback") &&
          req.query.nextauth?.includes("credentials") &&
          req.method === "POST"
        ) {
          return null
        }
        // Revert to default behaviour when not in the credentials provider callback flow
        return decode(params)
      },
    },
    adapter,
    providers: [
      CredentialsProvider({
        name: "Credentials",
        credentials: {
          email: {},
          name: {},
          password: {},
        },
        async authorize(credentials, req) {
          if (!credentials) return null

          const { name, email, password } = credentials

          let user: User | null = null

          if (name && email && password) {
            user = await prisma.user.create({
              data: {
                name,
                email,
                password: await bcrypt.hash(password, 10),
              },
            })
          } else {
            user = await prisma.user.findUnique({
              where: {
                email,
              },
            })

            if (!user) return null
            if (!user.password) return null
            if (!bcrypt.compareSync(password, user.password)) {
              return null
            }
          }

          return {
            id: user.id,
            name: user.name,
            email: user.email,
            image: user.image,
          }
        },
      }),
      GoogleProvider({
        clientId: env.GOOGLE_CLIENT_ID,
        clientSecret: env.GOOGLE_CLIENT_SECRET,
      }),
    ],
    pages: {
      signIn: "/account/signin",
    },
    session,
  }
}

export default async function auth(req: NextApiRequest, res: NextApiResponse) {
  // Do whatever you want here, before the request is passed down to `NextAuth`
  console.log(
    "AUTH",
    (process.env as any).NEXTAUTH_URL,
    env.NEXTAUTH_URL,
    (process.env as any).VERCEL_URL
  )
  return await NextAuth(req, res, authOptions(req, res))
}

but for some reason the logs in the callbacks and adapter are never reached when fetching the session. The login instead works fine.
I've no clue of what's wrong..

I found out what my problem was. Apparently when you login with the default form next-auth changes the cookie from next-auth.session-token to __Secure-next-auth.session-token in production.
If instead you use the function signIn in a custom form it doesn't, so the session works in a local environment but not in production.

I'm not sure if this is a bug or intended, but manually setting the session cookie name fixed the issue:

  ...
  cookies: {
    sessionToken: {
      name: "next-auth.session-token",
      options: {
        httpOnly: true,
        sameSite: "lax",
        path: "/",
        secure: env.NODE_ENV === "production",
      },
    },
  },
  ...

@mattiaz9 I face the same issue, your solution helped me solved it.

I think this is nor a bug or intended, since we're doing the customization from the start. Cheers!

See my repo, I've succesfully deployed to vercel, I am using postgresql as db

It's working here: https://nextauth.abehidek.me

you save me

@abehidek God bless you and your family 🙏 🙏 🙏 I will pray for you in my local church.

The described workaround really works great. Thanks a lot for that. I now try to figure out, why it works, but I have quite a hard time to wrap my head around the next-auth source code. The workaround seems to force that getSessionAndUser is called even for a credential provider. Is this correct? How does it do that? By returning a string in JWTs encode, or null in decode?

i am using using mongobd adapter, the adapter create the session in the db but the entire session async function block seems to be skipped there by not returning session to the client which takes me back to the initial issue dont know ho to wrap around it.

import NextAuth from "next-auth"
import { MongoDBAdapter } from "@next-auth/mongodb-adapter"
import clientPromise from "../auth/lib/mongodb"
import { MongoClient } from 'mongodb';
import bcrypt from 'bcrypt'
import GoogleProvider from "next-auth/providers/google";
import FacebookProvider from "next-auth/providers/facebook";
import CredentialsProvider from "next-auth/providers/credentials";

// Modules needed to support key generation, token encryption, and HTTP cookie manipulation 
import { randomUUID } from 'crypto'
// import Cookies from 'cookies'
import { setCookie, getCookie } from 'cookies-next';
import { encode, decode } from 'next-auth/jwt'



const MONGODB_URI = process.env.MONGODB_URI
// next auth starts here

export default async function handler(req, res) {
  const adapter = MongoDBAdapter(clientPromise)
  let userAccount = null
  // Do whatever you want here, before the request is passed down to `NextAuth`
  const generate = {}
  generate.uuid = function () {
    return uuidv4()
  }

  generate.uuidv4 = function () {
    return ([1e7] + -1e3 + -4e3 + -8e3 + -1e11).replace(/[018]/g, c =>
        (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
    )
  }
// Helper functions to generate unique keys and calculate the expiry dates for session cookies
  const generateSessionToken = () => {
    // Use `randomUUID` if available. (Node 15.6++)
    return randomUUID?.() ?? generate.uuid()
  }

  const fromDate = (time, date = Date.now()) => {
    return new Date(date + time * 1000)
  }

  //    callbacks for the sessions
const callbacks = {
  async redirect({ url, baseUrl }) {
    // Allows relative callback URLs
    if (url.startsWith("/")) return `${baseUrl}${url}`
    // Allows callback URLs on the same origin
    else if (new URL(url).origin === baseUrl) return url
    return baseUrl
  },
  async signIn({ user, account, profile, email, credentials }) {
    console.log("User Signin Start: ", user)
    // Check if this sign in callback is being called in the credentials authentication flow. If so, use the next-auth adapter to create a session entry in the database (SignIn is called after authorize so we can safely assume the user is valid and already authenticated).
    if (req.query.nextauth.includes('callback') && req.query.nextauth.includes('credentials') && req.method === 'POST') {
      if (user) {
          const sessionToken =  generateSessionToken()
          const sessionMaxAge = 60 * 60 * 24 * 7; //7Days
          const sessionExpiry = fromDate(sessionMaxAge)

          console.log("Session token is: ", sessionToken)
           console.log("sessionExpiry: ", sessionExpiry);
          
          await adapter.createSession({
              sessionToken: sessionToken,
              userId: user.username,
              expires: sessionExpiry
          })
          
          setCookie("next-auth.session-token", sessionToken, {
            expires: sessionExpiry,
            req: req,
            res: res,
          })
          console.log("user Session: ", user)
         
      }   
  }
    return true
  },

  async jwt({ token, user, account, profile, isNewUser }) {
    console.log("JWT callback. Got User: ", user)
    if (typeof user !== typeof undefined) {
      token.user = user;
    }
    return token
  },

  async session({ session, token}) {

    console.log("Session. Got User: ", session, token)
    if (userAccount !== null) {
      console.log("UserAccount Session Generation: ", user)
      session.user = {
        name: userAccount.name,
        email: userAccount.email,
      };
    console.log("Session.user: ", session.user)
    // return session
  }
  if (
    token && typeof token.user !== typeof undefined && (typeof session.user === typeof undefined ||
      (typeof session.user !== typeof undefined && typeof session.user.id === typeof undefined))
  ) {
    session.user = token.user
  }
  if (typeof token !== typeof undefined) {
    session.token = token
  }
  console.log("Session: ", session)
  return session
},
}

  const options = {
      session: {
              strategy: "database",
              maxAge: 7 * 24 * 60 * 60,
              updateAge: 24 * 60 * 60,
              // generateSessionToken: () => {
              //   return randomUUID?.() ?? randomBytes(32).toString("hex")
              // }    
            },
      jwt: {
        // Customize the JWT encode and decode functions to overwrite the default behaviour of storing the JWT token in the session cookie when using credentials providers. Instead we will store the session token reference to the session in the database.
        encode: async (token, secret, maxAge) => {
            if (req.query.nextauth.includes('callback') && req.query.nextauth.includes('credentials') && req.method === 'POST') {
                // const cookies = new Cookies(req,res)

                // const cookie = cookies.get('next-auth.session-token')
                const cookie = getCookie("next-auth.session-token", { req: req });

                console.log("pure Cookie: ", cookie);

                if(cookie) return cookie
                else return ''

            }
            // Revert to default behaviour when not in the credentials provider callback flow
            return encode(token, secret, maxAge)
        },
        decode: async (token, secret) => {
            if (req.query.nextauth.includes('callback') && req.query.nextauth.includes('credentials') && req.method === 'POST') {
                return null
            }

            // Revert to default behaviour when not in the credentials provider callback flow
            return decode(token, secret)
        }
      },
      debug: process.env.NODE_ENV === "development",
      adapter,
      secret: process.env.NEXTAUTH_SECRET,
      providers: [

        CredentialsProvider({
          name: 'Credentials',
          async authorize(credentials, req) {
            const client = new MongoClient(MONGODB_URI, {},) 
            try {
                await client.connect()
            } catch (e) {
                console.error(e)
            }
            const email = credentials.email
            const password = credentials.password
            //Get all the users
            const users = client.db().collection('users')
            //Find user with the email  
            const user = await users.findOne(
              {
                  $or: [
                      { email: email }, { username: email }
                  ]
              }
            )

          //   //Not found - send error res
            if (!user) {
                client.close();
                throw new Error('No user found with this credential')
            }

            console.log("Authorize User Credentials: ", user)
            //Check hased password with DB password
            const checkPassword = bcrypt.compareSync(password, user.password)
            //Incorrect password - send response
            if (!checkPassword) {
                client.close();
                throw new Error('Password doesnt match')
            }
            //Incorrect password - send response
            if (!checkPassword) {
                client.close();
                throw new Error('Password doesnt match')
            }
            //Else send success response
            userAccount = {
              id: user._id,
              name: user.name,
              email: user.email,
            };
            client.close();
            return userAccount;
        },
          
        }),
        GoogleProvider({
        clientId: process.env.GOOGLE_CLIENT_ID,
        clientSecret: process.env.GOOGLE_CLIENT_SECRET,
        allowDangerousEmailAccountLinking: true,
        }),
        FacebookProvider({
            clientId: process.env.FACEBOOK_CLIENT_ID,
            clientSecret: process.env.FACEBOOK_CLIENT_SECRET
        }),
      // ...add more providers here
    ],
    callbacks: callbacks,
    pages: {
      signIn: '/signin',
      signOut: '/signout',
      error: '/auth/error', // Error code passed in query string as ?error=
      verifyRequest: '/auth/verify-request', // (used for check email message)
      // newUser: '/auth/new-user' // New users will be directed here on first sign in (leave the property out if not of interest)
    }, 
    
  }

  return await NextAuth(req, res, options)

}

on getting this one working i will working session deletion on user sihn out but this is really giving me headache

Did you ever get this working? I have the exact same issue.

do you have an example of this?

honestly not sure what's wrong with your code.
nextauth is returning status code 500, which means something is not right within your code and there could be an unhandled exception error.

try to debug your code and see what is causing the status 500.

i followed @nneko's comment on how to switch to database strategy and it helped a lot
#4394 (reply in thread)

here is his blogpost:
https://branche.online/next-auth-credentials-provider-with-the-database-session-strategy/

this helped a lot with fixing my issues.

I recently checked and getServerSession() doesn't show user's session data in server components and API routes. 😢
It shows JWEInvalid: Invalid Compact JWE error.

Also having this Invalid Compact JWE error @codingapple1 , did you find a solution?

me too, wtf, any fixes?

yes

@Ahmadh26 made this change but doesn't seem to work either.

The problem I've got is that in my [...nextauth].ts file I'm exporting the handler which requires the request and response for checking if the request query has a callback and credentials, as described in the solutions above.

Even if I move the authOptions out of the handler and export/import it separately , it will still need the request and response as arguments.

Are you using getServerSession in your app? If so, do you mind sharing how?

Example:

  const session = await getServerSession(context.req, context.res, authOptions(req, res)

@hmar13 i'll be more than happy to help out with the issue itself. if you'd like we can take this on discord and i can probably share some code snippets there if you're okay with it?

edit: my discord is in my bio if you're interested.

Will do, thanks!

@hmar13 were you able to figure this out? facing the same issue.

@Kartik4152 I gave it a few more try's but couldn't make it work, sorry. This on top of other problems that kept arising with NextAuth put me off the whole thing tbh. Just using iron-session now and did the OAuth myself.

@tydolla00 you won't get signIn errors in the catch block. you need to await the promise and check if there's an error

const res = await signIn("credentials", {
  ...data,
  redirect: false,
});

if (res?.error) {
  toast({
    variant: "destructive",
    description: res.error,
  });
}

@glendell03 maybe you're missing some envs, maybe this could help debug: process.env.NODE_ENV === "development" X debug: true.
I will link a repo and host it on Vercel in the coming days.

@decovicdev I got this error
on localhost It does have session but on the deployed version no session

Localhost

Deployed

@glendell03 that error has been posted by another user, I have updated the solution since.

encode: async (arg) => {
          if (isCredentialsCallback) {
            const cookie = cookies().get("next-auth.session-token");

            if (cookie) return cookie.value;
            return "";
          }

          return encode(arg);
        },

the cookie is an object, make sure to return the cookie values in the encode function from next-auth option.

I hope there is more explanation regarding what the authorization flow is according to this setting, what the purpose of the JWT callback in the auth config is, because we are using a database session instead of a JWT token? Mainly, it's the JWT callback that I find difficult to wrap my head around. Or are there any reference materials I can look into?

Update: I found this article that explains a lot. https://clerk.com/blog/combining-the-benefits-of-session-tokens-and-jwts
Maybe the next step is to renew JWT tokens in the middleware or elsewhere?

Sent you a friend request!