Is NextAuth middleware enough to secure all pages and APIs?

[hunghvu]

Question 💬

For context, I'm using Google Auth, and export { default } from "next-auth/middleware" to secure pages / APIs. Whenever a user navigates to any pages or calls an API (from browsers or third-party programs like Postman) in an unauthenticated state, a sign-in page is returned. This is as expected.

Traditionally, I always do both client-side and server-side check-in authentication flow. For example:

// Client side - pseudo code
authenticated ? render(Page) : navigateTo(SignInPage);

// Server side - pseudo code
sessionCookie ? fetchApi() : return Unauthorized;

With the middleware, is it safe to assume I can completely ignore the traditional approach, and make NextAuth.js middleware a safe one-size-fits-all solution? This is under the assumption that there are no vulnerabilities.

I usually use Firebase, which requires more manual configurations and is sometimes quite troublesome (both SSR and CSR). It would be great if NextAuth.js can alleviate everything with a few lines of code.

Example images of Postman and curl are below.

How to reproduce ☕️

N/A

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[ThangHuuVu]

Yes, middleware is our cleanest solution for protecting API routes and pages!
Here are some references to get started:

• Docs: https://next-auth.js.org/configuration/nextjs#middleware
• Example: https://github.com/nextauthjs/next-auth-example. See admin routes.

[hunghvu]

Neat! This should be better clarified in the documentation then. Indeed, I would not think about middleware if I was not familiar with other frameworks.

Looking over #3982, seems like the updated documentation only shows securing pages with middleware, but does not mention its effect on API endpoints.

[pedro-stark]

Maybe I just don't know how but I was not able to protect my API routes.
Because of this: https://nextjs.org/docs/messages/returning-response-body-in-middleware

Any ideas?

[balazsorban44]

@pedro-stark not sure what you mean, you don't need that feature for our Middleware to work. Middleware will execute for every path, even API routes by default.

[pedro-stark]

Sorry, I need to clarify: I was not able to send a http status (i.e. 401) as a response to the request.
I can protect the API, but I wasn't able to find out how to correctly respond since next.js tells me to only use rewrite or redirect.

[OwenVey]

If I'm understanding this page correctly, this only works when using JWTs correct? Is there an elegant solution to locking down an entire app using middleware when using the database strategy? If not, what is the current reccomended way of doing so when using strategy: "database"?

[ThangHuuVu]

Unfortunately, it's not possible to use the database strategy with middleware at the moment due to the DB limitation. We are still eagerly waiting for an edge-compatible database to be able to run NextAuth.js on the middleware entirely.
Please see the https://next-auth.js.org/getting-started/example page for the recommendation 🙏

[SawkaDev]

Any idea why token would be null inside of the authorized callback? I am signed in.

[subimage]

Providing a middleware strategy for database adapters would be great. Stuck on this at the moment.

[bochensamsung]

Hi I am trying to use middleware to protect every possible route, is there a one line code using matcher to protect any route? Thanks.
I am Trying

export { default } from 'next-auth/middleware';
export const config = {
  matcher: ['/(.*)'],
}

but what shows up is an infinite loop url with error message: "localhost redirected you too many times."

[ShahriarKh]

Does this help?
https://clerk.com/blog/skip-nextjs-middleware-static-and-public-files

export const config = { matcher: ['/((?!.*\\.).*)'] };

[AlexOla-NG]

hi @bochensamsung , if I understand you correctly, you are asking if there is a way to protect every possible route.

If that's the case, I think running the code without the config object should fix the inifinite loop problem

[devdaim6]

Hello everybody ,
I just wanted to know that is there any way to use middle-ware for the pages which are inbuilt in next-auth.
For example like /api/auth/signin is one among the pages it has , but what problem i am facing is i want to protect this route using middle-ware for whenever user is logged in, the login page (i.e. /api/auth/signin) should not be accessible to user.
I have done it using the custom pages but i need to know is there any way possible to use inbuild pages and protect that route ?

[oscarcoding]

Is this also meant to cover page and API urls in the new Next JS v14? Is there a debugging option that proves that the middleware is in fact being called, and with what options and what results?

My middleware consists only of the single line:

export { default } from "next-auth/middleware"

The pages are not automatically protected. In each page I have to

const { data: session, status } = useSession()
if (!session) {
// show the login dialog
}

The API is not automatically protected. In each API method I have to:

const session = await getServerSession(authOptions)
if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })

So I have to manually check in every single page and every single API. This feels wrong, surely the middleware is meant to handle this before the page / API is even hit?

I have got everything wrapped in a SessionProvider in the RootLayout ~/layout.tsx:

<SessionProvider>{children}</SessionProvider>

And I have ~/app/api/auth/[...nextauth] setup correctly with:

const authOptions = { ... etc ... }
const handler = NextAuth(authOptions)
export { handler as GET, handler as POST }

I'm using the prisma adapter and the AzureAD provider.

In both the page and the API, session is returning the correct object when logged in and null when logged out. And the auth tables have profile info added, tokens etc added. So the auth is working - its just not doing the automatic protection. It only works manually.

This is running locally, with Node v20.11, Next v14.0.3, NextAuth v4.24.5

[markCwatson]

I am having the same problem as @oscarcoding. The documentation is really bad for this. I literally copy/paste examples and they do not work. I am on next-auth/v4, Next v14, Node v19.

I want to expand the default middleware (particularly in API routes), extract the JWT, and perform certain actions.

[ricardasjak]

I also don't understand how to protect API routes with the middleware, it kinda works, but returns html response as it redirects to the login page. So react-query cannot parse such response. I want to force 401 error instead of redirect, when it's an api route request.

I am still on pages router on Next v13 and Next-auth v4.
Any help, any advice?