auth callback is never called in middleware

[adriancuadrado]

Environment

  System:
    OS: Linux 6.11 Ubuntu 24.04.2 LTS 24.04.2 LTS (Noble Numbat)
    CPU: (4) x64 Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
    Memory: 1.91 GB / 7.10 GB
    Container: Yes
    Shell: 5.2.21 - /bin/bash
  Binaries:
    Node: 22.13.1 - ~/.nvm/versions/node/v22.13.1/bin/node
    npm: 11.4.0 - ~/.nvm/versions/node/v22.13.1/bin/npm
  Browsers:
    Chrome: 137.0.7151.103
  npmPackages:
    next: 15.3.4 => 15.3.4 
    next-auth: ^5.0.0-beta.28 => 5.0.0-beta.28 
    react: ^19.0.0 => 19.1.0

Reproduction URL

https://github.com/adriancuadrado/authjs-middleware-bug

Describe the issue

import { auth } from "@/auth";

export default auth(() => {
  console.log("Hello world from app/middleware.ts");
});

That "Hello world" message is never displayed. Therefore, the middleware is never run.

How to reproduce

Run npm run dev, go to http://localhost:3000/ and check the logs.

Expected behavior

According to this article, middleware.ts should run. But it doesn't regardless of whether there is an authorized callback in auth.ts or not:

You can also use the auth method as a wrapper if you’d like to implement more logic inside the middleware.

[adriancuadrado]

What's the point of being able to pass a callback in middleware.ts? What kind of logic could possibly only be implemented in that file but not in auth.ts? Could you please provide an example in the documentation where it would be useful to pass a callback to middleware.ts? The current example in the documentation is not useful because you can do that in auth.ts too.

[lucien-loua]

Hi @adriancuadrado ,

Thanks for sharing the repo. I believe the issue lies in the placement of your middleware.ts file. Since you're using the src/ directory structure with the App Router, middleware.ts should not be placed in src/app/, but rather directly inside src/, at the same level as the app/ folder.

According to the official Next.js documentation:
https://nextjs.org/docs/app/getting-started/route-handlers-and-middleware#convention-1

If you are using the App Router, the middleware.js or middleware.ts file should be placed in the same directory as your app directory (not inside it).

Correct structure:

project-root/
└── src/
    ├── app/
    └── middleware.ts  ← this is where it should be

Current structure:

project-root/
└── src/
    └── app/
        └── middleware.ts  ← this will be ignored by Next.js

Moving the middleware.ts file to src/ and restarting your dev server should resolve the issue.

Let me know if that helps!

[adriancuadrado]

@lucien-loua I can confirm that it was a matter of placing the file in the correct place. My bad. Sorry for the inconvenience.

Also, could you please answer my question from this comment?

What's the point of being able to pass a callback in middleware.ts? What kind of logic could possibly only be implemented in that file but not in auth.ts? Could you please provide an example in the documentation where it would be useful to pass a callback to middleware.ts? The current example in the documentation is not useful because you can do that in auth.ts too.

[lucien-loua]

@lucien-loua I can confirm that it was a matter of placing the file in the correct place. My bad. Sorry for the inconvenience.

Also, could you please answer my question from this comment?

What's the point of being able to pass a callback in middleware.ts? What kind of logic could possibly only be implemented in that file but not in auth.ts? Could you please provide an example in the documentation where it would be useful to pass a callback to middleware.ts? The current example in the documentation is not useful because you can do that in auth.ts too.

Glad it worked!

Regarding your question:

The purpose of passing a callback to auth() in middleware.ts is to run dynamic logic with access to the request object. This is not possible in auth.ts.

The callback gives you access to req.method, req.url, and req.nextUrl.pathname. These are useful for route-specific authorization or logging.

Official docs: https://authjs.dev/getting-started/session-management/protecting#nextjs-middleware

Extended version of your example:

import { auth } from "@/auth";

export default auth((req) => {
  console.log("Hello world from middleware.ts");

  const isAdminRoute = req.nextUrl.pathname.startsWith("/admin");
  const user = req.auth?.user;

  if (isAdminRoute && user?.role !== "admin") {
    return Response.redirect(new URL("/unauthorized", req.url));
  }

  // Allow the request if no conditions matched
  return;
});

This works only in middleware.ts because you are inspecting the request in real time. In contrast, auth.ts is just configuration. It doesn’t have access to the incoming request path or method.

So the callback is useful when you need middleware-level access control or inspection before the rest of your app runs.

[adriancuadrado]

@lucien-loua

The purpose of passing a callback to auth() in middleware.ts is to run dynamic logic with access to the request object. This is not possible in auth.ts.

But it IS possible:

src/auth.ts

import NextAuth from "next-auth";

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [],
  callbacks: {
    authorized: async ({ request }) => {
      console.log("Request url: " + request.url);
      return true;
    },
  },
});

In fact I just discovered something interesting that makes me think that the documentation is a bit misleading: The authorized callback is run twice when wrapping the middleware and route with auth().

Hello world from auth.ts
Hello world from app/middleware.ts
Hello world from auth.ts
Hello world from app/api/admin/route.ts
 GET / 200 in 9ms

However, the reference documentation of authorized() has this description:

Invoked when a user needs authorization, using Middleware.

If it really uses the middleware, shouldn't it run only once?

[adriancuadrado]

I've updated the code in case you want to take a look:
https://github.com/adriancuadrado/authjs-middleware-bug

The reason why auth.ts is run twice is because both the middleware and the route are wrapped in auth().

The reason why the middleware accepts a callback even though you can just use authorized() is because the callback has the same signature that you'd use in route.ts.

Mistery solved 😊

[lucien-loua]

Thanks for the detailed reply, Adrien.

You're right that the authorized callback can technically access the request when defined inside auth.ts. However, the confusion comes from how auth() behaves depending on where and how it’s called.

According to the official Auth.js documentation, the recommended way to integrate middleware is:

// middleware.ts
export { auth as middleware } from "@/auth";

This setup avoids redundant executions of the authorized callback. When both the middleware and a route are manually wrapped using auth(), the callback is invoked once per call, which results in two executions: one during the middleware phase and another when the route handler runs.

In your case, the logs confirm that behavior:

• First authorized() call: from middleware.ts
• Second authorized() call: from the route handler wrapped with auth()

This isn’t a bug, but a result of explicitly invoking auth() twice.

Now to clarify a subtle but important point: while the callback in middleware.ts can help with early route-based filtering or redirects, the Auth.js docs also emphasize:

You should not rely on middleware exclusively for authorization. Always ensure that the session is verified as close to your data fetching as possible.

This means that even if middleware is used for early access control, routes and APIs should still verify the session, either by wrapping with auth() or using auth() inline to access the session explicitly. So the recommended structure becomes:

• Use export { auth as middleware } in middleware.ts for global session enforcement.
• Use auth() in route handlers where session access is required to gate logic or fetch user-specific data securely.

So while you're correct that request info is available in auth.ts, the reason a callback is accepted in middleware.ts is to give developers an ergonomic way to handle route-based logic early in the lifecycle without requiring full duplication of logic or unnecessary session lookups when they’re not strictly needed.

In short, the distinction is about keeping responsibilities clear: middleware can handle simple checks like URL-based access control or redirects, but route handlers should remain responsible for secure session verification before accessing any sensitive data.

[MoscoviumAlchemist]

@lucien-loua I can confirm that it was a matter of placing the file in the correct place. My bad. Sorry for the inconvenience.
Also, could you please answer my question from this comment?

What's the point of being able to pass a callback in middleware.ts? What kind of logic could possibly only be implemented in that file but not in auth.ts? Could you please provide an example in the documentation where it would be useful to pass a callback to middleware.ts? The current example in the documentation is not useful because you can do that in auth.ts too.

Glad it worked!

Regarding your question:

The purpose of passing a callback to auth() in middleware.ts is to run dynamic logic with access to the request object. This is not possible in auth.ts.

The callback gives you access to req.method, req.url, and req.nextUrl.pathname. These are useful for route-specific authorization or logging.

Official docs: https://authjs.dev/getting-started/session-management/protecting#nextjs-middleware

Extended version of your example:

import { auth } from "@/auth";

export default auth((req) => {
console.log("Hello world from middleware.ts");

const isAdminRoute = req.nextUrl.pathname.startsWith("/admin");
const user = req.auth?.user;

if (isAdminRoute && user?.role !== "admin") {
return Response.redirect(new URL("/unauthorized", req.url));
}

// Allow the request if no conditions matched
return;
});
This works only in middleware.ts because you are inspecting the request in real time. In contrast, auth.ts is just configuration. It doesn’t have access to the incoming request path or method.

So the callback is useful when you need middleware-level access control or inspection before the rest of your app runs.

Thanks for clearly explaining these concepts. One question, in my testing, this kind of example results in typescript errors:

The inferred type of 'default' cannot be named without a reference to '../../../../node_modules/next-auth/lib/types'. This is likely not portable. A type annotation is necessary.

Is that happening for others too? What's the recommended way to fix those, cast the export as any? or as unknown as NextAuthMiddleware ? Casting as NextAuthMiddleware by itself results in:

Conversion of type 'AppRouteHandlerFn' to type 'NextAuthMiddleware' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
  Types of parameters 'ctx' and 'event' are incompatible.
    Property 'params' is missing in type 'NextFetchEvent' but required in type 'AppRouteHandlerFnContext'.ts(2352)

[exhilaratedguy]

Correct if I'm wrong, but the point of wrapping your custom middleware with the auth function that's exported is to be able to add stuff such as internationalised routing.

Since you need both NextAuth's automatically configured middleware along with your own logic for route handling, this is the way to handle it in a single location.

Now... It does run the code that's wrapped by auth on middleware.ts even if the authorized callback returns false and I'm not entirely sure if that should be considered the right approach (or if it's intended at all)? I ended up moving the checks I had in the callback to the middleware itself as a workaround.

[adriancuadrado]

@MoscoviumAlchemist @exhilaratedguy I'm going to close this issue because I solved my problem and I don't like keeping issues open. Please consider opening your own issues for the comments that you wrote, and feel free to put a link to those issues here for reference if you want.