[auth][error] MissingAdapter: Email login requires an adapter (firebase adapter and Resend)

[tidianeb5]

Adapter type

@auth/firebase-adapter

Environment

  System:
    OS: macOS 14.4.1
    CPU: (14) arm64 Apple M3 Max
    Memory: 4.13 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.7.3 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /opt/homebrew/bin/yarn
    npm: 10.5.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 124.0.6367.60
    Safari: 17.4.1
  npmPackages:
    @auth/firebase-adapter: ^1.6.0 => 1.6.0 
    next: ^14.1.4 => 14.2.2 
    next-auth: ^5.0.0-beta.15 => 5.0.0-beta.16 
    react: ^18.2.0 => 18.2.0 

Reproduction URL

https://github.com/tidianeb5/missing-adapter-issues-firebase-adapter-and-resend

Describe the issue

Issue Description

I'm encountering an error when trying to use email login with the next-auth package:

[auth][error] MissingAdapter: Email login requires an adapter. Read more at https://errors.authjs.dev#missingadapter

at assertConfig (webpack-internal:///(middleware)/./node_modules/@auth/core/lib/utils/assert.js:138:24)
at Auth (webpack-internal:///(middleware)/./node_modules/@auth/core/index.js:88:95)

Configuration

I'm using the following configuration:

• next-auth version: 5.0.0-beta.15

According to the documentation, if you have an adapter that is not compatible with the Edge runtime, you need to separate the configuration into two files.

1. auth.config.ts:

import type { NextAuthConfig } from "next-auth";

import Resend from "next-auth/providers/Resend"; 


export default {
  providers: [
   Resend
  ],
} satisfies NextAuthConfig;

2. auth.ts (API Route):

import NextAuth from "next-auth";

import authConfig from "@/auth.config";
import { FirestoreAdapter } from "@auth/firebase-adapter";

import { cert } from "firebase-admin/app";



export const {
  handlers: { GET, POST },
  auth,
  signIn,
  signOut,
} = NextAuth({
  ...authConfig,
  pages: {
    signIn: "/auth/login",
    error: "/auth/error",
  },


  adapter: FirestoreAdapter({
    credential: cert({
      projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID!,
      clientEmail: process.env.SERVICE_ACCOUNT_CLIENT_EMAIL!,
      privateKey: process.env.SERVICE_ACCOUNT_PRIVATE_KEY!.replace(
        /\\n/g,
        "\n"
      ),
    }),
  }),
  session: { strategy: "jwt" },
 
});

3. [...nextauth].ts (API Route):

export { GET, POST } from "@/auth";

4. middleware.ts:

import NextAuth from "next-auth";

import authConfig from "@/auth.config";
import {
  DEFAULT_LOGIN_REDIRECT,
  apiAuthPrefix,
  authRoutes,
  publicRoutes,
} from "@/routes";



const { auth } = NextAuth(authConfig);




export default auth((req) => {
  const { nextUrl } = req;
  const isLoggedIn = !!req.auth;

  const isApiAuthRoute = nextUrl.pathname.startsWith(apiAuthPrefix);
  const isPublicRoute = publicRoutes.includes(nextUrl.pathname);
  const isAuthRoute = authRoutes.includes(nextUrl.pathname);

  if (isApiAuthRoute) {
    return null;
  }

  if (isAuthRoute) {
    if (isLoggedIn) {
      return Response.redirect(new URL(DEFAULT_LOGIN_REDIRECT, nextUrl))
    }
    return null;
  }

 

  if (!isLoggedIn && !isPublicRoute) {
    let callbackUrl = nextUrl.pathname;
    if (nextUrl.search) {
      callbackUrl += nextUrl.search;
    }

    const encodedCallbackUrl = encodeURIComponent(callbackUrl);

    return Response.redirect(new URL(
      `/auth/login?callbackUrl=${encodedCallbackUrl}`,
      nextUrl
    ));
  }

  return null;
})

// Optionally, don't invoke Middleware on some paths
export const config = {
  matcher: ['/((?!.+\\.[\\w]+$|_next).*)', '/', '/(api|trpc)(.*)'],
}

Expected Behavior

I expect the email login functionality to work correctly without any errors.

Please let me know if you need any additional information or if I should provide more details about my setup or the steps I've taken to reproduce this issue.

How to reproduce

Just clone the project , and add envs : AUTH_SECRET,SERVICE_ACCOUNT_PRIVATE_KEY,SERVICE_ACCOUNT_CLIENT_EMAIL,NEXT_PUBLIC_FIREBASE_PROJECT_ID ...

Expected behavior

Not showing the error .

[NickFoden]

Hi Mabiri,

I am not a maintainer but saw your issue here and want to give a heads up that next-auth expects firebase-admin of version 11 currently.

• next-auth/packages/adapter-firebase/package.json

  Line 47 in b4187cc

  "firebase-admin": "^11.4.1"

if you can try with firebase-admin 11 that might be a path forward. I am trying to raise a PR for updating to firebase-admin 12 at the moment so maybe firebase-admin 12 can work in near future.

Also if you can share any more errors you are getting, does checking types maybe tsc --noEmit flare up any issues from your project ?

[tidianeb5]

hello NickFoden , thanks for your respond ,

i try firebase-admin version 11.4.1 , but having the same issues ..

[ndom91]

Thanks for pointing this out, it looks liek this is a bug in the assertion process (checking to make sure yuo've added a database adapter) when using an email adapter and also doing the edge-runtime split config.

Basically, it's checking in the edge runtime (where you don't have the adapter in the auth.js config), to ensure that the provider (resend) can operate correctly. But actually, we're not sending any emails in the middleware (edge runtime) anyway, so we can delay that checking to only happen in places where we would actually be sending an email (like in the normal serverles functions / backend / API route).

I'll try to find some time and see where we can make this change. If anyone wants to take a stab that'd be great too :)

EDIT: Notes for later:

• The current check is here: packages/core/src/lib/utils/assert.ts:219
• Could be moved somewhere like packages/core/src/lib/utils/env.ts:7 (setEnvDefaults) maybe? 🤔 Not sure

[ndom91]

For now, since the Email provider actually isn't doing any work in the middleware / edge runtimes where its throwing this error, you can move your Email provider to the config where you have your adapter as well, so they both don't get included in the middleware / edge runtime enviornments.

That should avoid this error and still have your Resend / whatever Email provider be able to send emails and use up verificationTokens upon signin 👍

[tidianeb5]

thanks you @ndom91 for your respond , i try mooving the Email provider the config where i have my adapter , but still i am having the same errors...

[matthijsgroen]

I'm having exactly the same issue :-) Curious about a fix!

[matthijsgroen]

I tried using a fake adapter in de middleware part. It won't show errors now, but resend does not work either...

The middleware.ts file

import NextAuth from "next-auth";
import { Adapter, VerificationToken } from "next-auth/adapters";
import { authConfig } from "./auth.config";

const fakeEmailAdapter: Adapter = {
  createVerificationToken: (verificationToken: VerificationToken) => undefined,
  useVerificationToken: (params: { identifier: string; token: string }) => null,
  getUserByEmail: (email: string) => null,
};

export default NextAuth({ ...authConfig, adapter: fakeEmailAdapter }).auth;

[tidianeb5]

I tried using a fake adapter in de middleware part. It won't show errors now, but resend does not work either...

The middleware.ts file

import NextAuth from "next-auth";
import { Adapter, VerificationToken } from "next-auth/adapters";
import { authConfig } from "./auth.config";

const fakeEmailAdapter: Adapter = {
  createVerificationToken: (verificationToken: VerificationToken) => undefined,
  useVerificationToken: (params: { identifier: string; token: string }) => null,
  getUserByEmail: (email: string) => null,
};

export default NextAuth({ ...authConfig, adapter: fakeEmailAdapter }).auth;

did you find a solution ?

[tidianeb5]

Hi good morning, anyone have any updates here ? Thank you 🙇 😊

[NickFoden]

nothing ???

Maybe rephrase as

Hi good morning, anyone have any updates here ? Thank you 🙇 

[akoskm]

I'm experiencing the same issue with MongoDB, Prisma, and SendGrid. I also opened a discussion (#10942), but it looks like we're experiencing the same issue.

[tidianeb5]

nothing ???

Maybe rephrase as

Hi good morning, anyone have any updates here ? Thank you 🙇 

thank you , i will take it in mind , next time , 👌

[akoskm]

For now, since the Email provider actually isn't doing any work in the middleware / edge runtimes where its throwing this error, you can move your Email provider to the config where you have your adapter as well, so they both don't get included in the middleware / edge runtime enviornments.

That should avoid this error and still have your Resend / whatever Email provider be able to send emails and use up verificationTokens upon signin 👍

This is a good idea! I don't want to do anything in my middleware because I use const session = await auth() on my pages. However, when I include the default middleware config suggested here https://authjs.dev/getting-started/installation?framework=next.js

while having this in auth.js:

import NextAuth from "next-auth";
import Sendgrid from "next-auth/providers/sendgrid";
import type { DefaultSession } from "next-auth";

declare module "next-auth" {
  interface Session {
    user: {
      credits?: number;
    } & DefaultSession["user"];
  }
}

import { PrismaAdapter } from "@auth/prisma-adapter";
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [
    Sendgrid({
      apiKey: process.env.AUTH_SENDGRID_KEY,
      from: process.env.AUTH_SENDGRID_FROM,
    }),
  ],
  adapter: PrismaAdapter(prisma),
});

the app works between subsequent refreshes, and I'm getting no errors in the console, but once I log in and I have a session in cookies, I'm getting the following error:

Do you have any suggestions on how to fix this if i don't want to do anything in my middleware?

Any help is appreciated! 🙏

[NickFoden]

Hi @akoskm I think you want to initialize the prisma client differently because of hot reloading etc.

Check prisma + next.js examples for the recommended approach

• https://github.com/prisma/prisma-examples/blob/latest/typescript/rest-nextjs-api-routes/src/lib/prisma.ts

I use this / forget where I picked it up from, but similarly I use this below for next.js projects (and I also do not use the app router, am waiting for more stable/mature release that is less verbose and also when "we" have React 19 etc)

// src/adapters/prisma.ts

import { PrismaClient } from "@prisma/client";

const prismaClientSingleton = () => {
  return new PrismaClient();
};

type PrismaClientSingleton = ReturnType<typeof prismaClientSingleton>;

const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClientSingleton | undefined;
};

const prisma = globalForPrisma.prisma ?? prismaClientSingleton();

if (process.env.NODE_ENV !== "production") {
  globalForPrisma.prisma = prisma;
}

export default prisma;

[akoskm]

Thanks @NickFoden! I know where you got that from 😃 I asked the AI on the Prisma site what's the best way to expose the Prisma client object, and it replied with a similar code:

import { PrismaClient } from "@prisma/client";

const prismaClientSingleton = () => {
  return new PrismaClient();
};

declare const globalThis: {
  prismaGlobal: ReturnType<typeof prismaClientSingleton>;
} & typeof global;

const prisma = globalThis.prismaGlobal ?? prismaClientSingleton();

export default prisma;

if (process.env.NODE_ENV !== "production") globalThis.prismaGlobal = prisma;

I tried the code you suggested as well - which does almost the same thing - but I'm getting the same error.

[akoskm]

For now, since the Email provider actually isn't doing any work in the middleware / edge runtimes where its throwing this error, you can move your Email provider to the config where you have your adapter as well, so they both don't get included in the middleware / edge runtime enviornments.

That should avoid this error and still have your Resend / whatever Email provider be able to send emails and use up verificationTokens upon signin 👍

hey @ndom91 I'd love to give this a shot and create PR that fixes the issue based on your first comment. However, after reading this, I'm curious if you're aware that the workaround that was suggested doesn't make the issue go away.

Considering that, do you think simply moving the check is sufficient? I can give it a shot after work and see if it fixes the issue and if the login/session still works.

[ndom91]

@akoskm Yeah, go for it!

I think it shuold be sufficient, but haven't had time to dig in much further myself. We'd appreciate if you or anyone else could spend some time digging into this a bit more 🙏 . It might be as simple as just moving that assertion to a bit later in the process.

[ndom91]

Also regarding the prisma errors, it seems like Prisma is still tryign to be executed on the edge runtime somewhere. What version of prisma are you using? As of 5.12.0-ish it should be more "edge compatible" in certain situations.

• Our article on edge compatibility: https://authjs.dev/guides/edge-compatibility
• Prisma's new docs on edge compat: https://www.prisma.io/docs/orm/prisma-client/deployment/edge/overview