Middleware crashes when JWT is expired

[pmmmwh]

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 v4.5.1 (latest version at the time of writing), a security patch was released to ensure JWTs are expired alongside the cookies.
However, that has caused some side-effects - the middleware now crashes with HTTP 500 whenever an expired JWT hits the server:

[JWTExpired: "exp" claim timestamp check failed]

I am not sure this is an intentional behaviour or an oversight? Coming from the user's perspective, I felt like the middleware should have caught this and handled as if there is no session, instead of throwing. How it is handled could dependant on the route - e.g. profile should return 401, and for non-auth routes probably short circuit the session updates.

Reproduction

1. Obtain an expired JWT
2. Hit the Next.js server wired up with the Auth0 middleware
3. Boom, HTTP 500

Additional context

No response

nextjs-auth0 version

4.5.1

Next.js version

14.2.28

Node.js version

22.14.0

[frederikprijck]

Thanks, this is definetly not intentional. I am working on a fix here.

Any chance you can elaborate what you exacly mean when you say to obtain an expired JWT? And how do you use it? Even though I think we definitely should handle this better, I am also trying to understand and reproduce your exact use-case to ensure it's also solved in the changes being introduced.

[pmmmwh]

Any chance you can elaborate what you exacly mean when you say to obtain an expired JWT? And how do you use it?

We have a fairly standard set up actually - with the middleware and extra auth checks on every page. Obtaining an expired JWT is just a way to reproduce the problem.

The only special thing (that makes the issue very pronounced for us) is@ that we use short absolute/idle session durations (both 1h).

[frederikprijck]

I tried a few scenario's, but was not able to reproduce. I still think we can handle the expired JWE better, but I am not able to reproduce your exact scenario in order to retrieve the error you are getting.

What I tried was:

1. Absolute Duration, and use an Access Token that expires after the cookie does.

export const auth0 = new Auth0Client({
    session: {
        rolling: false,
        absoluteDuration: 2 * 60, // 2 minutes in seconds
    }
})

When I start the app and login, I wait until the cookie expires and navigate again. I see the middleware being triggered, but it can not find a session because the cookie was not send along the request, and the user appears logged out, as expected.

2. Absolute Duration, and use an Access Token that expires before the cookie does.

Then, I did the same but ensured the JWT inside of the cookie expires before the Cookie does. When I navigate at the moment the Access Token is expired, but the cookie isnt, I can see the access token to be refreshed, and the cookie to be updated with that access token.

3. Absolute Duration, and use an Access Token that expires before the cookie does while not using refresh tokens.
That made me try without refresh tokens, but still use an access token that expires before the cookie does, which, once the access token is expired, but the cookie isnt, results in:

AccessTokenError: The access token has expired and a refresh token was not provided. The user needs to re-authenticate.

I am only getting this error because I am explicitly using auth0.getAccessToken() in the middleware, if I don't I get no error at all.

Any chance you can try and reproduce the behavior in a small application to help us troubleshoot?

[maloyuso]

Hi! We are experiencing the same issue. It has become a dependency for successfully updating to Next.js 15

[sleitor]

For me this problem appears has when:

1. make access token short 1-2 min
2. refresh token - 1 day
3. open the app (with server-action button)
4. wait 2-3 min
5. click to this button (without refresh the page)

I use from docs
auth0.middleware(request);

Next.js 15.3.2

For now I wrote this workaroud but this looks dirty

  let resp: NextResponse;
  try {
    resp = await auth0.middleware(request);
  } catch (error) {
    console.warn('[auth0] Token expired — redirecting to /login', error);
    const loginUrl = new URL('/auth/login', request.url);
    loginUrl.searchParams.set('returnTo', request.nextUrl.pathname);
    return NextResponse.redirect(loginUrl);
  }

... // some logic for nonce and another stuff

return resp;

[frederikprijck]

I tried the following using next@15.3.2 and @auth0/nextjs-auth0@4.5.1 :

• I configured the API in Auth0 to issue tokens that expire after 120 seconds.
• I added the following Server Action:

async function trigger() {
    'use server'
    // Mutate data
    console.log('Called server action');
  }

• And called it like this:

<form action={trigger}><button>Trigger</button></form>

• My middleware looks like this:

import type { NextRequest } from "next/server"

import { auth0 } from "./lib/auth0"

export async function middleware(request: NextRequest) {
  return await auth0.middleware(request);
}

Then I open the app and I waited 5 minute. Once I click the button, I am not getting an error.

I created a branch that contains my changes to our sample app, any chance someone can reproduce it in that application? I think this would help speed up reproduction, and confirm resolution.

To pull it locally, you can do:

• git clone https://github.com/auth0/nextjs-auth0
• git checkout repro/2081
• cd nextjs-auth0
• npm i -g pnpm
• cd examples/with-shadcn

Then, rename .env.template to .env and fill in information and update lib/auth0 to include the authorizationParameters.audience and run:

• pnpm i
• pnpm run dev

Then, point your browser to http://localhost:3000 and try and reproduce.