AD integrations and large cookies (413)

[MadsFrost]

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

Preamble

Greetings,

I'm experiencing issues with the getAccessToken method in nextjs-auth0. The problem relates to the AD integration setup that Auth0 provides and the context it gives back about the user. We get hit with 413's for users that have too many groups attached to them - following an AD integration sign-in from a user that has existed for 9 years with 100+ groups attached and that sum up to a lot of characters.

Cookies and header sizes

Like many other posts on the internet relating to Auth0, we’re also experiencing problems with too large headers being sent back and fourth to proxy api’s. Our issue is not necessarily a bug as much as it is a misunderstanding/documentation issue. We cannot seem to understand how to avoid sending an entire catalogue of all the groups from the user active directory.

We have an instance of a user including over 100+ groups with a sum of 6000 characters. This generates 7 session cookies that sums up to around a size of 27.96kb. I get that we could just increase header sizes and move on to the next issue - but this could also potentially be a security issue or that we maybe have confused ourselves in how we have everything setup.

Our stack:

• NextJS monolith running @auth0/nextjs-auth0@4.9.0
• An internal API with seperate middlewares signing and validating the jwt token passed in header from either the NextJS monolith or the auth0-react-native package.

So the questions are:

1. Can we choose how much context to get back about the user in different parts of our stack? Completely ignoring groups and somehow fetch it when handling the requests on the server?
2. Is the client at fault? Do they simply have too many groups attached and it's a liability in itself?
   2.1 Client did attempt to remove groups not in use but they are a lead with oversight over hundreds of on-going projects and would love to keep their user centralized to everything.

Our NextJS middleware code

export async function middleware(request: NextRequest) {
  try {
    const newResponse = await auth0.middleware(request);
    const urlCopy = request.nextUrl.clone();
    let newPath: string;
    let apiHost: string;

    // Here we attempt to handle proxies so we can pass the token to our internal api's
    if (urlCopy.pathname.startsWith(REDACTED)) {
      newPath = urlCopy.pathname.replace(REDACTED, "");
      apiHost = ...;
    } else if (urlCopy.pathname.startsWith(REDACTED)) {
      newPath = urlCopy.pathname.replace(REDACTED, "");
      apiHost =...;
    } else {
      return newResponse;
    }

    const newHost = new URL(apiHost);

    if (newHost.host) {
      urlCopy.host = newHost.host;
      urlCopy.port = newHost.port || "";
      urlCopy.protocol = newHost.protocol || "https:";
      urlCopy.pathname = newPath;

      // Get Auth0 session and access token
      let accessToken:
        | { token: string; expiresAt: number; scope?: string }
        | undefined;
      try {
        accessToken = await auth0.getAccessToken(request, newResponse);
      } catch (e) {
        accessToken = undefined;
      }
      const maybeCookieToken = request.cookies.get("authorization");

      const requestHeaders = new Headers(request.headers);
      requestHeaders.set(
        "Authorization",
        "Bearer " + (accessToken?.token ?? maybeCookieToken?.value),
      );

      return NextResponse.rewrite(urlCopy, {
        request: {
          headers: requestHeaders,
        },
      });
    }

    return newResponse;
  } catch (error) {
    // Handle JWT expiration specifically
    // if (error instanceof Error && error.message.includes('JWTExpired')) {
    // Redirect to login or refresh the session
    return NextResponse.redirect(new URL("/auth/login", request.url));
    // }
    throw error;
  }
}

I hope I provided enough information - otherwise please get back to me if you are missing anything :folded_hands:

Reproduction

1. Add a user in an active directory
2. Attach 100+ groups with around 6000 characters in total to the user's ad context.
3. Sign-in to the client using your azure directory integration in Auth0
4. Get hit by a 431 - because the headers are way too large when attaching the bearer token.
5. Look at the application -> cookies -> session_0... session_xyz and sum the size of the cookies.
6. Attempt to send this bearer to external api's (which from what I understand are default capped to 16kb) and get also receive a 431 there (max 16kb)

Additional context

No response

nextjs-auth0 version

4.9.0

Next.js version

15.3.5

Node.js version

>= 21

[MadsFrost]

Just to add additional context:
We have had a look at #2209 hence the upgrade to nextjs-auth0@4.9.0, but regardless the transactional cookies does not appear to be a problem for us as of this moment.

[MadsFrost]

I won't close this issue - as it could be useful having more perspectives. So I'll let the Auth0 team handle that, but we originally solved it in the same manner as how Nik from the Auth0 team detailed here

[tusharpandey13]

Hi @MadsFrost 👋

We cannot seem to understand how to avoid sending an entire catalogue of all the groups from the user active directory.

You can filter what data gets saved in the session using the beforeSessionSaved hook:

const auth0 = new Auth0Client({
  // ... other config
  beforeSessionSaved: async (session, idToken) => {

    // filter the group claims
    const updatedSession = yourCustomClaimsFilterMethod(session);
    return updatedSession;
  }
});

[tusharpandey13]

Hi @MadsFrost, we are reviewing old issues and came across this one. It seems that a solution was provided a while ago using the 'beforeSessionSaved' hook. Can you please let us know if the suggested solution solved your problem? If we don't hear back from you in a week, we will assume that the issue is resolved and close it.

[MadsFrost]

Hi @MadsFrost, we are reviewing old issues and came across this one. It seems that a solution was provided a while ago using the 'beforeSessionSaved' hook. Can you please let us know if the suggested solution solved your problem? If we don't hear back from you in a week, we will assume that the issue is resolved and close it.

Hi, the issue is resolved yes. Thanks for taking your time to look at it.