Auth0 middleware sets cookie and reloads page.tsx on every Server Action call

[kompiro]

Checklist

• The issue can be reproduced in the nextjs-auth0 sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Auth0 middleware sets cookies and triggers page reloads on every Server Action call

Cause

• Next.js revalidates Router Cache when cookies are updated in Server Actions Next.js Deep Dive: Caching
• auth0-nextjs works as follows on requests to Server Action when processed by middleware: auth-client.js

1. Retrieve the session from the sessionStore
2. If session can be retrieved, update sessionStore for rolling update
   a. For the default StatelessSessionStore, encrypt the originalSessionData in the session into jwe, chunk it, and store it in the cookie. In jwe, the cookie is updated each time because it includes the time of creation: stateless-session-store.ts
   b. For StatefulSessionStore, session ID is chunked into jwe and stored in cookie. jwe includes generation time, so cookie is updated every time stateful-session-store.ts

Reproduction

Assumption

• In middleware, set up a call to auth0.middleware
• Reproduce with or without sessionStore set in Auth0 configuration

Reproduction

1. Call Server Action
2. Because auth0.middleware performs authentication processing, a Set-Cookie is added to the response header, X-Action-Revalidated becomes [[],0,1], and NextJS Client follows the instructions to reload RSC (React Server Component) reloading the RSC (React Server Component) as instructed.

server-action-call-revalidates-by-set-cookie.mov

Additional context

When server action call, please skip to update cookie. We can identify server action when the request has Next-Action header.

Or if session.rolling is false, skip cookie update process and manage cookie lifetime based on the first cookie created. This TODO comment suggests this behavior

nextjs-auth0 version

4.6.0

Next.js version

15.3.2

Node.js version

22.10

[tusharpandey13]

👋 Thanks for reporting this issue, we have planned this for SDK improvements and you can expect a resolution soon. Meanwhile, we will be communicating here for any other information.

[backlands]

I am wondering if we can disable this handling simply by either:

1. Skip authentication middleware for server actions by checking for the Next-Action header in the middleware function directly such as if(request.headers.get('Next-Action'))?
2. Skip authentication middleware globally for server actions by only matching on the request missing the Next-Action header (shown below)?

export const config = {
  matcher: [
    {
      source: '/((?!_next|api|static|public|favicon.ico|robots.txt).*)',
      missing: [
        { type: 'header', key: 'Next-Action' },
      ],
    },
  ],
};

I haven't had the chance to review the library to the depth needed yet, but is there anything in the library that could be negatively effected from skipping triggering the auth0.middleware for Server Actions?

[tusharpandey13]

Hi @backlands, you can definitely skip the middleware invocation for your server actions if requried. The middleware is responsible for handling calls to the auth api-endpoints and running hooks. It updates session in the process and commits transactions if needed.

Note that you can still do manual auth checks like calling getSession and checking it's value.

In fact, for running custom logic that potentially bypasses the auth0 handling of default auth endpoints like /auth/login, we recommend intercepting calls in the middleware itself based on url (similar to what you are doing with request.headers.get('Next-Action')) and returning a custom NextResponse, see #1895 (comment)

[backlands]

Thank you for the prompt response! Perfect, I suspected as much but always good to validate that there was not something specific implemented for actions that would not occur on page loads and we would be degrading the library functionality unintentionally. Sounds like this approach is fine then and can handle the use case here until more specific functionality is implemented.

We do in fact already use the methods outlined in #1895 for our internationalization process to add the relevant cookie data when missing. We are also performing validation steps using getSession in various actions to verify access and various other user details in our process. Much appreciated once again @tusharpandey13

[tusharpandey13]

Sure, let us know if there's anything else on this that's required, we will be closing this shortly.

[viktormoskalev07]

I spent 4 hours debugging to figure out why everything was re-rendering multiple times before I finally found this post. This is a terrible and confusing behavior — please fix it as soon as possible.
Even a simple "use server" function with a console.log triggers a full re-render of the entire page.

[shinobijs]

This is a critical issue with usability and security impact. When auth0 moved to middleware (edge) we could no longer retrieve additional user data from our database in the callback, and decided to implement a Server Action for this. It becomes an endless loop with this bug.

As a workaround, should we skip the middleware for Server Actions? How does that impact security?

[ik-southpole]

@tusharpandey13 could you please share some information on this issue? As it stands now, this problem is very annoying because it also revalidates other things such as next-intl. We have recently bumped into an infinite fetch due to that because auth0 sets cookies so aggressively even when there is no need to roll sessions.

A basic example:

A user types in a search input, we call a server action to fetch results and use t to translate. As of now, this will cause infinite loop due to auth0.middleware setting cookies on every request revalidating everything.

// layout.tsx
import { NextIntlClientProvider } from "next-intl";
import type { ReactNode } from "react";

export interface LayoutProps {
  children: ReactNode;
}

export default async function Layout({
  children,
}: LayoutProps): Promise<ReactNode> {
  return (
    <html>
      <body>
        <NextIntlClientProvider>{children}</NextIntlClientProvider>
      </body>
    </html>
  );
}

// proxy.ts
import { NextRequest, type ProxyConfig } from "next/server";
import { auth0 } from "./auth0";

export const config: ProxyConfig = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

export async function proxy(req: NextRequest): Promise<Response> {
  return auth0.middleware(req);
}

// action.ts
"use server";

import { auth0 } from "./auth0";

export default async function action() {
  await auth0.getSession();
  console.log("action called");
}

// page.tsx
"use client";

import { useTranslations } from "next-intl";
import { useEffect, type ReactNode } from "react";
import action from "./action";

export default function PageClientFragment(): ReactNode {
  const t = useTranslations();

  useEffect(() => {
    void action();
    alert(t("message"));
  }, [t]);

  return null;
}

// auth0.ts
import { Auth0Client } from "@auth0/nextjs-auth0/server";

export const auth0 = new Auth0Client();

[Piyush-85]

Thanks for the detailed repro, @ik-southpole — this is the issue we're tracking.

Root cause: Rolling sessions emit a Set-Cookie header on every request, including server actions. When a server action response includes a Set-Cookie, Next.js invalidates its Router Cache, triggering an RSC refetch. In your case, that refetch re-provides NextIntlClientProvider, which changes the t reference, which fires your useEffect again — infinite loop.

Immediate workaround: Use the beforeSessionRolled hook to skip rolling on the route where the loop occurs:

// auth0.ts
import { Auth0Client } from "@auth0/nextjs-auth0/server";

export const auth0 = new Auth0Client({
  beforeSessionRolled: async (req) => {
    const isServerAction = req.headers.get("Next-Action") !== null;
    const isAffectedPage = req.nextUrl.pathname === "/your-page"; // scope to the specific route
    return !(isServerAction && isAffectedPage);
  },
});

Note: Avoid skipping rolling for all server actions globally — that would effectively disable rolling for users who interact primarily through actions. Scope it to the specific pages where the loop occurs.

Security impact: Safe. The session is still validated on every request; you're only choosing not to extend its TTL on those specific routes. getSession() and all access-control checks remain unaffected.

A proper SDK-level fix (suppressing the Set-Cookie when the session hasn't materially changed) is in progress — we'll update this issue when it ships.