Refreshing token in API route - subsequent request returns 401 and clears session

[adoprog]

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

I have a NextJS app with multiple /api routes that communicate to external system. I'm trying to get token refresh to work and so far isolated the following problem: after successful refresh, the session is updated, new session cookies are sent to the client, but the very next request to the same API route fails with 401 and cookies are cleared:

Reproduction

1. Be logged in to the app
2. Open /api/test route in a separate browser tab (route is wrapped into withApiAuthRequired and uses getAccessToken inside of it)
3. Wait / or force token refresh and reload the tab
4. Token is successfully refreshed and new session cookies are sent in response, all good so far
5. Reload the tab again
6. 401 error is returned and the session is cleared

Is there anything special I'm missing about API routes?

Additional context

No response

nextjs-auth0 version

1.9.3

Next.js version

12.1

Node.js version

16.20.0

[adoprog]

Upgraded the project to 2.6.3 and the same issue is reproducible.

[adamjmcgrath]

Hi @adoprog - thanks for raising this.

Have just tested this on the sample app with 2.6.3 installed and can't reproduce the issue you're describing.

Could you share an example repo that demonstrates the issue and I can debug it for you.

[adoprog]

I've just tested it on sample app (downloaded main branch, so "@auth0/nextjs-auth0": "^2.0.0") and can reproduce it, the changes I've made to work with our Auth0 instance are:

1. Modified startup script to allow larger headers (our token is quite large, otherwise it returned 431 error)
   "dev": "concurrently \"cross-env NODE_OPTIONS='--max-http-header-size=245760' next dev\" \"node api-server\"",

2. In the shows.js removed scope value, added our custom argument we need for refresh and set "refresh" to true to test it without waiting
   const { accessToken } = await getAccessToken(req, res, { scopes: [], authorizationParams: { custom_param: 'custom value', }, refresh: true });

3. Set all .env variables to our values, including AUTH0_AUDIENCE, set the scope to:
   AUTH0_SCOPE='openid profile email offline_access'

After I open (in a separate browser tab) http://localhost:3000/api/shows - it loads once and says '{"msg":"Your access token was successfully validated!"}', but on second load it returns '{"error":"not_authenticated","description":"The user does not have an active session or is not authenticated"}'

[adoprog]

Okay, after removing 'profile' from scope it seems to work... Could it be actually caused by token / session size?

[adamjmcgrath]

Could it be actually caused by token / session size?

Possibly, although the SDK is designed to handle larger sessions by breaking the cookie up into chunks - have just tested this on the sample app with a session > 4096 (cookie max size). How large is the session in bytes? Could you share a HAR file (with secrets redacted)?

[adoprog]

There is 5 chunks total when 'profile' is there and 4 when it is not. Attached the HAR file (two subsequent requests, when 'profile' is there). Thanks!

[adamjmcgrath]

Thanks for sharing the HAR file @adoprog - I think I see the issue

When you make the first request to /shows your session is divided into 5 chunks (0,1,2,3,4). When /shows refreshes the token the session is updated and, for whatever reason, is slightly smaller - the session is divided into 4 chunks (0,1,2,3) which results in a response with 4 chunked cookies.

But the response does not remove the the erroneous 5th chunk. So when the second request turns up with 5 chunks, the SDK puts all 5 together and gets an invalid session. (if you delete appSession.4 in chrome after the first request, you would get a 200)

For cases like yours where the session gets smaller and the number of chunks decreases, we need to delete any erroneous chunks - will raise some work to fix this. (Note: this should not be an issue in the new Beta because https://github.com/auth0/nextjs-auth0/blob/beta/src/auth0-session/session/stateless-session.ts#L142)

[adamjmcgrath]

@adoprog This has been fixed in https://github.com/auth0/nextjs-auth0/releases/tag/v2.7.0