Azure oAuth leading to 431 REQUEST_HEADER_FIELDS_TOO_LARGE in NextJS on Vercel

[TomHessburg]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

I've been putting together an application which uses Azure oAuth for the past week or so. Everything has been running smoothly, but I recently began receiving 431 REQUEST_HEADER_FIELDS_TOO_LARGE errors. Removing some scopes was working for a while, but at this point, even minimal scopes hits this issue. Ideally I'm trying to request my dynamics environment + offline_access scope to get a refresh token.

I haven't 1000% been able to rule out user error here, but everything I can tell matches up with what's in the docs. I've seen some similar issues from others, mainly using Svelte, and those recommended using the chunk helped functions, but theres no documentation on those.

For reference, I'm using the following while signing in:

export async function signInWithAzure() {
  const supabase = createClient();

  const { data } = await supabase.auth.signInWithOAuth({
    provider: "azure",
    options: {
      scopes: `${process.env.DATAVERSE_BASE_URL}.default offline_access`,
      redirectTo: `${process.env.BASE_URL_FOR_REDIRECT}/auth/callback`,
    },
  });

  if (data.url) {
    redirect(data.url);
  }
}

and the following middleware

import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({
    request,
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) =>
            request.cookies.set(name, value)
          );
          supabaseResponse = NextResponse.next({
            request,
          });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );
        },
      },
    }
  );

  // IMPORTANT: Avoid writing any logic between createServerClient and
  // supabase.auth.getUser(). A simple mistake could make it very hard to debug
  // issues with users being randomly logged out.

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (
    !user &&
    !request.nextUrl.pathname.startsWith("/login") &&
    !request.nextUrl.pathname.startsWith("/auth")
  ) {
    // no user, potentially respond by redirecting the user to the login page
    const url = request.nextUrl.clone();
    url.pathname = "/login";
    return NextResponse.redirect(url);
  }
  
  // IMPORTANT: You *must* return the supabaseResponse object as it is. If you're
  // creating a new response object with NextResponse.next() make sure to:
  // 1. Pass the request in it, like so:
  //    const myNewResponse = NextResponse.next({ request })
  // 2. Copy over the cookies, like so:
  //    myNewResponse.cookies.setAll(supabaseResponse.cookies.getAll())
  // 3. Change the myNewResponse object to fit your needs, but avoid changing
  //    the cookies!
  // 4. Finally:
  //    return myNewResponse
  // If this is not done, you may be causing the browser and server to go out
  // of sync and terminate the user's session prematurely!

  return supabaseResponse;
}

It's quite odd that this seems to be getting worse over time. I had no issues for the past week+, began having issues in my production deployment but only with all scopes, and now can't access anything in the prod deployment or my local, even with minimal scopes.

Hoping this isn't basic user error, but If it is, I'm not seeing where!

Any help greatly appreciated!

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Create a supabase application
2. Follow the docs for setting up an oauth app with azure
3. Add user_impersonation to your app registration API permissions in azure
4. authenticate with the scopes mentioned aboce
5. Run it for a while? 🤷‍♂️

Expected behavior

Supabase Azure oauth does not lead to 431 REQUEST_HEADER_FIELDS_TOO_LARGE.

Screenshots

System information

• OS: MacOS
• Browser (if applies): Any
• Version of supabase-js: 2.45.5
• Version of Node.js: 20.11.1 (Vercel), running 20.9.0 on my local

Additional context

Think that covers it!

[Arvoid00]

I have had this happen locally when I had multiple supabase sessions in cookies causing the header to be too large, or when I parsed an error message in the header which caused it too become too long. Hope that helps..

[oof2win2]

This has been happening to me for about the past 3 weeks as well. Can't get logs from Vercel as it doesn't execute my middleware and can't get a stable reproduction. Only happens for some users, but it's persistent.

[KeithT34]

This had happened to me, I had to manually remove the user from the authentication tab in Supabase, and when they reauthenticated again everything was fine.

For some reason there was more auth-tokens being sent from my supabase than there should of been, which made the header too large. Not sure what causes it (as this error also occured for me after a while of it just working fine) but its at least a temporary fix for now if it happens again.

[dexsnake]

I'm also running into this issue, but not with Vercel, on nginx.

We have a a few internal apps where employees login with Microsoft using Supabase. If they then try to access another of our apps that runs on an nginx server, they get a request header or cookie too large error.

After looking at the application cookies, I usually see 3 supabase auth token cookies that are very large.

This seems to only be happening after the initial login, because after a refresh happens, it goes down to 2 cookies. The size is still large, but about half the size of the initial login. Keeping it under the 8k header size.

For reference, I'm only getting the email and profile scopes.

[pstachula-dev]

Ok I solved the problem.
I checked my Nodejs based API server, it had a 16kb limit. My token was sent twice, both in the custom header bearer and with all cookies, in the Fetch option credentials: ‘include’.

In my case, it is a matter of isolating only the token that is sent to the API, and remove cookie header.

[rylincoln]

Ok I solved the problem. I checked my Nodejs based API server, it had a 16kb limit. My token was sent twice, both in the custom header bearer and with all cookies, in the Fetch option credentials: ‘include’.

In my case, it is a matter of isolating only the token that is sent to the API, and remove cookie header.

This was sorta my issue - but not because of sending things twice, just because the request header is around 22kb after Entra(Azure) Oauth flow happens.

First I had "fixed" the issue by updaing the nginx config to allow larger request headers, then the issue came back and i had to set the
ENV NODE_OPTIONS="--max-http-header-size=65536"
in my dockerfile (i'm using caprover to deploy nextjs 15 + supabase app) ...

I think it's finally resolved.

For me I added the ENV NODE_OPTIONS="--max-http-header-size=65536"

right before my last 2 lines to bring things up

...
# Set Node.js runtime options - increase max header size to 64kb (65536 bytes)
ENV NODE_OPTIONS="--max-http-header-size=65536"

# server.js is created by next build from the standalone output
# https://nextjs.org/docs/pages/api-reference/config/next-config-js/output
ENV HOSTNAME="0.0.0.0"
CMD ["node", "server.js"]