v4.0.7-beta.7 "InvalidStateError: The state parameter is invalid" in callback

[ltatakis-optaxe]

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

In my application I have the following code

export const auth0 = new Auth0Client({
  appBaseUrl: process.env.AUTH0_BASE_URL,
  domain: process.env.AUTH0_ISSUER_BASE_URL,
  clientId: process.env.AUTH0_CLIENT_ID,
  clientSecret: process.env.AUTH0_CLIENT_SECRET,
  signInReturnToPath: '/dashboard/trade',
  authorizationParameters: {
    scope: 'openid profile email offline_access',
    audience: process.env.AUTH0_AUDIENCE
  },
  async beforeSessionSaved(session) {
    return {
      ...session,
      user: {
        ...session.user
      }
    }
  },

  onCallback: async (startingError, ctx, session) => {
    if (startingError || !session) {
      console.error({ startingError }, 'Error starting callback')

      return NextResponse.redirect(
        new URL(ctx.returnTo || '/error', process.env.APP_URL)
      )
    }

    try {
      await afterCallback(session)

      return NextResponse.redirect(
        new URL(ctx.returnTo || '/', process.env.APP_URL)
      )
    } catch (error) {
      console.error({ error }, 'Error in after callback')

      return NextResponse.redirect(
        new URL(ctx.returnTo || '/error', process.env.APP_URL)
      )
    }
  }
})

In most of our setups this works as expected. However, in some scenarios when running within a virtual browser within our infrastructure we get the error

{
  startingError:  [InvalidStateError: The state parameter is invalid.] {
  code: 'invalid_state',
  name: 'InvalidStateError'
}

which is returned as the startingError of onCallback.

The auth0 credentials and config are all correct. The auth0 logs of the tenant themselves says the users logs in correctly.

The only response I have found about this is here. A 4 year old community post.

It does seem that within the Auth0 realm the Network tab is cleared after each process (email/password etc) but I have the same behaviour in our other environments but they log in successfully.

We have had these virtual browsers using v.3.5.0 for a while without this issue, so this is something new.

Reproduction

1. Use a virtual browser within a cluster or ci
2. Login
3. On the callback receive the error InvalidStateError
   but Auth0 platform says its successfully logged me in

Additional context

No response

nextjs-auth0 version

4.0.0-beta.7

Next.js version

15.0.3

Node.js version

v22.11.0

[guabu]

Hey @ltatakis-optaxe 👋 It sounds like the state is either missing in the callback URL or the transaction cookie might be missing.

You'll have to make sure the headless browser is preserving the transaction cookie and passing the query parameters back from Auth0 to your application to be able to consume that state and complete the transaction.

[ltatakis-optaxe]

@guabu you are correct it seems that its likely that the state parameter is missing from the callback URL. Auth0 developer support have advised me to solve this with https://auth0.com/docs/quickstart/spa/react/01-login#add-login-to-your-application eg loginWithRedirect from https://www.npmjs.com/package/@auth0/auth0-react.

As :

1. this worked appropriately in 3.5.0
2. we have not changed our approach or code relating to it.
3. Auth0 development support is advising the use of a function in @auth0/auth0-react

it would suggest this is a regression in the current version.

[ltatakis-optaxe]

I have managed to replicate the issue with the example sample application provided at https://github.com/auth0/nextjs-auth0/tree/v4.0.0-beta.9/examples/with-shadcn

The only changes I made to make it run with our environment is:
in file https://github.com/auth0/nextjs-auth0/blob/v4.0.0-beta.9/examples/with-shadcn/lib/auth0.ts
I set it with

export const auth0 = new Auth0Client({
  appBaseUrl: process.env.AUTH0_BASE_URL,
  domain: process.env.AUTH0_ISSUER_BASE_URL,
  clientId: process.env.AUTH0_CLIENT_ID,
  clientSecret: process.env.AUTH0_CLIENT_SECRET,
  authorizationParameters: {
    scope: "openid profile email offline_access",
    audience: process.env.AUTH0_AUDIENCE,
  },
});

this worked locally but in the headless browser I got "The state parameter is invalid"

[ltatakis-optaxe]

@guabu I have found the offending line, its here. While 3.5.0 had another way to determine the secure flag as seen here

The reasons this is an issue for us is because in our E2E environment are:

1. Our E2E environment does not have HTTPS. Setting HTTPS for our automated and ephemeral environment is time consuming and error prone. It has a Kubernetes cluster DNS that is used by the headless browsers without SSL. I appreciate this is not a common scenario.
2. If a NextJS application is not run via next dev, but is built via next build and run vianext startNextJs always sets the NODE_ENV=production. Therefore, when we try to test our release docker image that has been built via next build there is no way to configure it to not have the secure cookie for the automated tests.

Would you consider changing this logic OR adding some sort of parameter that we can at least knowingly turn this off in specific scenarios?

Thank you

[guabu]

Hey @ltatakis-optaxe 👋 Thanks for sharing more context!

As you pointed you, we set the secure attribute of the cookies to true in production environments since ideally this is the correct behavior we want to maintain but I can understand how that can be troublesome in the scenario you described.

We've decided to check the protocol of the APP_BASE_URL — if it's set to https:, we'll set the secure attribute to true. This is closer to the behavior of v3 and should hopefully make it easier to migrate.

The changes should be out in the next release (linked above).

[ltatakis-optaxe]

fantastic thank you @guabu

[ltatakis-optaxe]

@guabu the latest version 10 has fixed my issue. Thank you.