Support middleware for session-based authentication

[GeeWee]

Description 📓

Next-auth recently introduced middleware that validates JWT-tokens, which is a great step usability-wise.

Unfortunately those of us who are using alternate authentication methods such as session-based authentication don't have anything out of the box, and implementing a middleware like that yourself is trickier than you would expect, because you cannot simply pass the request in your middleware to getSession

This seems to be because the next-auth accesses headers via req.headers.cookie, but the type of the headers inside middleware is not an object, but a Headers object which must be accessed through req.headers.get("cookie")

I have implemented a middleware that works for session-based authentication. It does this by converting the relevant part of the request headers to an object

import type { NextFetchEvent, NextRequest } from 'next/server';
import { getSession } from 'next-auth/react';
import { NextResponse } from 'next/server';

export async function middleware(req: NextRequest, ev: NextFetchEvent) {
  const requestForNextAuth = {
    headers: {
      cookie: req.headers.get('cookie'),
    },
  };

  const session = await getSession({ req: requestForNextAuth });

  if (session) {
    console.log(session);

    // validate your session here

    return NextResponse.next();
  } else {
    // the user is not logged in, redirect to the sign-in page
    const signInPage = '/auth/signin';
    const signInUrl = new URL(signInPage, req.nextUrl.origin);
    signInUrl.searchParams.append('callbackUrl', req.url);
    return NextResponse.redirect(signInUrl);
  }
}

However I think this means that an extra fetch call will be made to the next-auth backend. One in the middleware, and one later on if you want to access the session in API calls.

Solution proposal 1: Middleware

It would be great if next-auth provided a middleware that did everything, like it does for the JWT-based flow

Solution proposal 2: Allow NextRequest in GetSession

Another great solution, which probably requires less work is to accept a NextRequest in getSession, which meant it could be used both client-side, server-side and in middleware.

It does not seem like there are many code changes needed to make this work.

Related issues:
#3136
#4042
#3151

How to reproduce ☕️

N/A

Contributing 🙌🏽

Yes, I am willing to help implement this feature in a PR

[balazsorban44]

Could you clarify what you mean by "session-based authentication"? Using a database for the session? In that case, it's currently not a NextAuth.js limitation, but simply that not many (if any) databases/ORMs support non-Node.js/Edge runtimes.

[herdma]

In that case, how would I go about securing an entire application if I want to also use a database for the session?

I previously did this via _middleware directly in the pages directory, but after adding the prisma adapter, I can no longer access the token in my middleware to authorize requests.

I managed to get it to work in general by adding this to my page:

export async function getServerSideProps(context) {
  const session = await getSession(context);
  
  if (!session) {
    return {
      redirect: {
        destination: '/auth/login',
      },
    };
  }

  return {
    props: {},
  };
}

However it seems a bit redundant to add this check to every single one of my pages and API routes. Is there a better way?

[GeeWee]

Yes, sorry, I mean using a database for the session. I'm not sure why that shouldn't be possible on an edge runtime, even if it migth require an extra fetch call (like we do client-side when we call getSession)

[balazsorban44]

Middlewares are executed before navigation and such they should be as fast as possible. An extra fetch call would be unnecessary, so we should avoid it. Until database ORMs/databases are optimized (i.e. SDKs not Node-only and databases are better distributed) for Edge, we should not pursue supporting them, in my opinion.

[GeeWee]

That's a fair opinion - if that's your decision I won't argue with that, though personally I think having the option would've been nice. Thanks for your thoughts.

[dev-fredericfox]

I am fairly new to TypeScript, and TypeScript is unhappy with:
const session = await getSession({ req: requestForNextAuth });
It's throwing following message:

Type '{ headers: { cookie: string | null; }; }' is missing the following properties from type 'IncomingMessage': aborted, httpVersion, httpVersionMajor, httpVersionMinor, and 46 more.ts(2740)

Can someone explain how to fix this?

[GeeWee]

Unfortunately only via //@ts-ignore - While the Nextauth currently says it needs the whole request, it seems to only use the cookies, which is why the above middleware works in practice, even though the types don't check.

[DohanKim]

const requestForNextAuth = {
   headers: {
     cookie: req.headers.get('cookie') ?? undefined,
   }, 
 };

This can be a solution.

[muhaimincs]

Hope this will stay longer

[piec]

@GeeWee did you try to do a production build?
Apparently await getSession(...) uses stuff that is not available in the Next.js Edge Runtime (where middlewares run).

./node_modules/@babel/runtime/helpers/construct.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Middleware pages/me/_middleware

Correct?

Cheers,
Pierre

[GeeWee]

Ah, no I actually only got so far as to test it on the development server. Sucks if it doesn't actually work in production..!

[kachar]

I get the same output when I run yarn build

info  - Creating an optimized production build
Failed to compile.

./node_modules/next-auth/node_modules/@babel/runtime/helpers/construct.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Middleware pages/dashboard/_middleware

Import trace for requested module:
./node_modules/next-auth/node_modules/@babel/runtime/helpers/wrapNativeSuper.js
./node_modules/next-auth/core/errors.js
./node_modules/next-auth/lib/logger.js
./node_modules/next-auth/react/index.js
./pages/dashboard/_middleware.ts

./node_modules/next-auth/node_modules/@babel/runtime/helpers/isNativeFunction.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Middleware pages/dashboard/_middleware

Import trace for requested module:
./node_modules/next-auth/node_modules/@babel/runtime/helpers/wrapNativeSuper.js
./node_modules/next-auth/core/errors.js
./node_modules/next-auth/lib/logger.js
./node_modules/next-auth/react/index.js
./pages/dashboard/_middleware.ts


> Build failed because of webpack errors
error Command failed with exit code 1.

[denik1981]

Edge runs a small subset of the V8 runtime, thus many things that are available in Node, aren't in the Edge and consequently in the middleware which was primarily thought to run at the Edge.

As a temporary solution until a database adapter for the Edge shows up, you can defer the logic that requires the NodeJS engine to a NextJS API route because the Fetch API is available in the middleware, and at the API route we can finish our the authentication flow with all the tools available.

Something to be aware of is that the middleware won't send the headers it got from the browser to the fetch request thus we have to copy those so we can get the session token to check for a session, otherwise, the authentication will always retrieve as false.

I know this is not the most desirable solution cause it doesn't make too much sense to make HTTP requests within the server but it is the only workaround I can think of, and to be honest, works very well.

So your _middleware will be something like this:

import { NextRequest, NextResponse } from 'next/server'

export default async function middleware(req: NextRequest) {
  const url = req.nextUrl.clone()
   
  // fetch here requires an absolute URL to the auth API route 
  const {
    data: { auth },
  } = await fetch(`${url.origin}/api/authSSR`, {
    headers: req.headers,
  }).then((res) => res.json())

  // we patch the callback to send the user back to where auth was required
  url.search = new URLSearchParams(`callbackUrl=${url}`).toString()
  url.pathname = `/api/auth/signin`

  return !auth ? NextResponse.redirect(url) : NextResponse.next()
}

And then you will have an API route (name it as you wish) to check if the user is logged in

export default async function handle(
  req: NextApiRequest,
  res: NextApiResponse
) {
  const session = await getSession({ req })
  res.json({ data: { auth: !!session } })
}

Hope it helps!

[aapdomingues]

Hi @denik1981 . Tks for sharing this approach!
I had the same issue and I've tried your approach! This works to trigger the refreshToken through the middleware, but the cookies was not updated. Should I do something different to force the cookies update in this case?

I am using the 'jwt' strategy. I'm trying trigger the refresh the token in the server side because the hook useSession (client-side) will not cover all scenarios that I have. Then I would like to check in the server side for all request that I receive (I check first if accessToken has expired before trigger the getSession to avoid many hits on it).

[aapdomingues]

After research a little more, I found this article that helps me to solve my case: https://dev.to/mabaranowski/nextjs-authentication-jwt-refresh-token-rotation-with-nextauthjs-5696

Maybe this can help more people!

[arisAlexis]

as per the documentation the middleware example only works with jwt sessions and I can agree that it would be nice to make it work with database sessions too.

[f0-x]

What would be the best approach for Database-based sessions on a Next JS App then? What did you decide for your app?

[willzittlau]

For the use case where you want to protect certain routes, Next 13's Layouts have allowed us to skip using middleware while authenticating with a database. For example:

/app/admin/layout.tsx
"use client";

import { Typography } from "@mui/material";
import { useSession } from "next-auth/react";

// checks authorized users
export default function Layout({
  children, // will be a page or nested layout
}: {
  children: React.ReactNode;
}) {
  const session = useSession();
  const role = session?.data?.user?.role;

  return role === "admin" ? (
    <>{children}</>
  ) : (
    <Typography>{"You aren't authorized to view this page."}</Typography>
  );
}

Protects /admin/* routes.

[Djboy08]

What about for api routes? This may protect against just them seeing the page, but the api routes are still available

[willzittlau]

@Djboy08 example from one of our api routes:

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  const session = await getServerSession(req, res, authOptions);
  if (session && session.user) {
    if (req.method === "POST") {
      return handlePost(req, res);
    }
    if (req.method === "PATCH") {
      return session.user.role === "admin"
        ? handlePatch(req, res)
        : res.status(403);
    }
    if (req.method === "GET") {
      return handleGet(req, res);
    }
  } else {
    // Not signed in
    res.status(401);
  }
  res.end();
}

Maybe this helps?

[Djboy08]

This is not amazing as this would have to be on every single api route correct?

[willzittlau]

This is not amazing as this would have to be on every single api route correct?

Correct, its not a perfect solution but we don't have a complex api structure so it's been working fine for our use case

[Djboy08]

Is there any update on this? any fixes?

[sifue]

I was able to obtain a session from the /api/auth/session API using the Edge Function Runtime. This code can be deployed in a production environment.

import { NextRequest, NextResponse } from 'next/server'

export const config = {
    runtime: 'edge',
}

export default async function handler(req: NextRequest) {

    const resSession = await fetch(process.env.NEXTAUTH_URL + '/api/auth/session', {
        headers: {
            'Content-Type': 'application/json',
            'Cookie' : req.headers.get('cookie') || '',
        },
        method: 'GET'
    });
    const session = await resSession.json();

    if (!session) {
        return new Response(JSON.stringify({text:'Not signed in.', status: 401}), { status: 401 });
    }
    
    console.log({session});

    return new Response(JSON.stringify({session}), { status: 200});
}

[Djboy08]

Sadly this is still just the same way of doing things as previously mentioned.

[Crayon-ShinChan]

I use Prisma adapter and then in my middleware.ts, I have the code (Next-Auth v4)

const authMiddleware = withAuth(
  // Note that this callback is only invoked if
  // the `authorized` callback has returned `true`
  // and not for pages listed in `pages`.
  (req: NextRequest) => intlMiddleware(req),
  {
    callbacks: {
      authorized: ({ req: { cookies } }) => {
        const sessionToken = cookies.get("next-auth.session-token");
        return sessionToken != null;
      },
    },
    pages: {
      signIn: customizedAuthRoutes.signIn,
    },
  },
);

If user has logged in, authorized() return true

My whole middleware is integrated with i18n, it's looks like this:

import { withAuth } from "next-auth/middleware";
import createIntlMiddleware from "next-intl/middleware";
import { NextRequest } from "next/server";

const locales = ["en", "zh", "zh-TW"];
const customizedAuthRoutes = {
  signIn: "/api/auth/signin",
  // signOut: "/api/auth/signout",
  // error: "/api/auth/error",
};
const publicPages = ["/", ...Object.values(customizedAuthRoutes)];

const intlMiddleware = createIntlMiddleware({
  locales,
  defaultLocale: "en",
});

const authMiddleware = withAuth(
  // Note that this callback is only invoked if
  // the `authorized` callback has returned `true`
  // and not for pages listed in `pages`.
  (req: NextRequest) => intlMiddleware(req),
  {
    callbacks: {
      authorized: ({ req: { cookies } }) => {
        const sessionToken = cookies.get("next-auth.session-token");
        return sessionToken != null;
      },
    },
    pages: {
      signIn: customizedAuthRoutes.signIn,
    },
  },
);

export default function middleware(req: NextRequest) {
  const publicPathnameRegex = RegExp(
    `^(/(${locales.join("|")}))?(${publicPages.join("|")})?/?$`,
    // TODO: use "i" flag?
    "i",
  );
  const isPublicPage = publicPathnameRegex.test(req.nextUrl.pathname);

  if (isPublicPage) {
    return intlMiddleware(req);
  } else {
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    return (authMiddleware as any)(req);
  }
}

export const config = {
  // this matcher will not work for redirect 404 page to correct locale
  matcher: ["/", "/(en|zh|zh-Hant)/:path*"],
  // matcher: ["/((?!api|_next|.*\\..*).*)"],
};

[triyanox]

I recently ran into this issue you can simply do something like this

import { getSession } from "next-auth/react";

// ..... rest of your code
const session = await getSession({
      req: {
        ...req,
        headers: {
          ...Object.fromEntries(req.headers),
        },
      },
   });
// ... rest of your code

[danielrotaermel]

For me using getSession in the middleware causes build errors like this -> #4265 (comment)

But you could use fetch as described by @denik1981 and @sifue
#4265 (comment)

This works for me

// middleware.ts
      ...

    authorized: async ({ req }) => {
      const resSession = await fetch(
        process.env.NEXTAUTH_URL + '/api/auth/session',
        {
          method: 'GET',
          headers: {
            ...Object.fromEntries(req.headers),
          },
        },
      );
      const session = await resSession.json();

      if (session?.user?.id != null) return true;
      return false;
    }
     
      ...

[DannelCu]

I recently ran into this issue you can simply do something like this

import { getSession } from "next-auth/react";

// ..... rest of your code
const session = await getSession({
      req: {
        ...req,
        headers: {
          ...Object.fromEntries(req.headers),
        },
      },
   });
// ... rest of your code

Thx men you save my life and I will tell you why, even wen I can get the token correctly if i make the request via postman etc with and old but valid token i can not get the updated information of the user, and because I am working on a plan based sistem where dates and resurces vary acordinly to the plan type it is critical for me to get the last updated info.

[triyanox]

Glad I could help !

[DannelCu]

Bro it works localy but give an error on Vercel, i think that maybe in other hosting would work

[sreenathOpenCV]

https://stackoverflow.com/questions/78447578/server-error-there-is-a-problem-with-the-server-configuration-check-the-server

help please