Refresh token rotation gets run twice with the middleware enabled, and then fails because the token has been revoked

[Vinnl]

Environment

  System:
    OS: Linux 6.8 Fedora Linux 40 (Container Image)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
    Memory: 5.51 GB / 15.33 GB
    Container: Yes
    Shell: 5.2.26 - /usr/bin/bash
  Binaries:
    Node: 20.11.0 - ~/.volta/tools/image/node/20.11.0/bin/node
    Yarn: 1.22.19 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
    npm: 10.2.4 - ~/.volta/tools/image/node/20.11.0/bin/npm
    pnpm: 8.14.2 - ~/.volta/bin/pnpm
  npmPackages:
    next: 14.2.3 => 14.2.3 
    next-auth: ^5.0.0-beta.18 => 5.0.0-beta.18 
    react: ^18 => 18.3.1 

Reproduction URL

https://github.com/Vinnl/next-auth-bug-repro/tree/refresh-token-rotation-pkce

Describe the issue

I'm not entirely well-versed in OAuth, so please bear with me.

I've set up the Spotify provider in a Next.js app using auth.js, and tried to implement refresh token rotation as described in the guide. I'm using JWT, not a database, to maintain a user session.

As I understand it (I think this is a PKCE thing?), the refresh token gets invalidated after use - and along with the new access token, you also get a new refresh token for the next rotation.

However, if the Next-Auth middleware is enabled, it appears to attempt to rotate the same refresh token multiple times, the first of which is successful, but after that resulting in errors because the token has now been revoked.

How to reproduce

1. git clone --branch refresh-token-rotation-pkce git@github.com:Vinnl/next-auth-bug-repro.git
2. Create a client ID and secret on https://developer.spotify.com/dashboard (Spotify Premium required, unfortunately).
3. Set AUTH_SECRET, AUTH_SPOTIFY_ID and AUTH_SPOTIFY_SECRET in .env.local.
4. pnpm install
5. pnpm run dev
6. Sign in using Spotify
7. Wait for two minutes (that's the time I set up to wait before refreshing the token)
8. Refresh the page

Expected behavior

The JSON output showing the current session gets:

  "error": "RefreshAccessTokenError"

and if you look at the terminal in which you ran pnpm run dev, you'll see something like:

Refreshed token: {
  access_token: '<snip>',
  token_type: 'Bearer',
  expires_in: 3600,
  refresh_token: '<snip>',
  scope: 'streaming user-modify-playback-state user-read-email user-read-private'
}
Could not refresh access token: { error: 'invalid_grant', error_description: 'Refresh token revoked' }
Could not refresh access token: { error: 'invalid_grant', error_description: 'Refresh token revoked' }

If you now were to make any API calls with the access token shown on the page, they'd get rejected.

The expected behaviour is for the session to contain a valid access token, not have the error, and for the logs to not show the "Refresh token revoked" error. And in fact, that is what seems to happen if you rm middleware.ts, I think?

[abencun-symphony]

I've resolved this by doing this:

In the middleware call auth but then inject the session via a request header:

if (session) {
  headers.set('X-Serialized-Session', btoa(encodeURIComponent(JSON.stringify(session))));
}

In your components, route handlers, wherever, just write and consume a helper method to deserialize and use the session:

import { headers } from 'next/headers';

export function readSession() {
  const encodedSession = headers().get('X-Serialized-Session');
  const decodedSession = typeof encodedSession === 'string' ? decodeURIComponent(atob(encodedSession)) : undefined;
  return decodedSession;
}

This absolutely prevents multiple calls to auth() that result in multiple token refreshes since only middleware is allowed to invoke it.

[frbarbre]

I'm running into the same issue, where you able to resolve it?

[ianvieira]

Based on @abencun-symphony input I was able to isolate which is the problem.

The middleware and the route function should be considered as 2 different servers and they communicate over HTTP.

The problem is that both invoke the auth(), in theory, only the first one (the middleware) should transform the token but this doesn't happen because when the middleware transforms the token, it transmits as a set-cookie header, not as a cookie header. Then when the route function tries to read from the cookie header and it will have the value before renewing, therefore it will try to renew it again.

My suggestion to fix it is on the getSession function on next-auth/lib/index.ts, to merge the set-cookie to the cookie. This way, the route function will receive the latest value and will not try to revalidate it, this is a change I did and it's working:

const cookiesToObject = (cookies) => {
  if(!cookies) {
    return {};
  }

  return cookies.split(";").reduce((acc, cookie) => {
    const [name, value] = cookie.split("=");
    return { ...acc, [name.trim()]: value };
  }, {});
};

const cookiesToString = (cookies) => {
  if(cookies.length === 0) {
    return "";
  }

  return Object.entries(cookies)
    .map(([name, value]) => `${name}=${value}`)
    .join(";");
};

const convertSetCookiesToCookies = (setCookies) => {
  return setCookies.map((cookie) => {
    const [nameValue, ...directives] = cookie.split(";");
    return nameValue;
  }).join(";");
}

async function getSession(headers, config) {
    const url = createActionURL("session",
    // @ts-expect-error `x-forwarded-proto` is not nullable, next.js sets it by default
    headers.get("x-forwarded-proto"), headers, process.env, config.basePath);

    const setCookies = headers.get("set-cookie");
    // By default, try using the cookie header
    let cookiesToUse = headers.get("cookie");
    
   // If there is set-cookie header, we need to merge it with cookie
    if(setCookies) {
      // For some reason when we try using getSetCookie from header, it's empty. But if we recreate the headers, we have it
      const headersToParse = new Headers(headers);
      // Convert cookies to an object to easily merge
      const cookiesObject = cookiesToObject(headersToParse.get("cookie"));
      // Convert the set-cookies to the same format as cookies (removing the other info) and then to an object
      const setCookiesObject = cookiesToObject(convertSetCookiesToCookies(headersToParse.getSetCookie() ?? []));
      // Merge both objects and convert back to string
      cookiesToUse = cookiesToString({ ...cookiesObject, ...setCookiesObject });
    }

    const request = new Request(url, {
        headers: { cookie: cookiesToUse },
    });

    return Auth(request, {
        ...config,
        callbacks: {
            ...config.callbacks,
            // Since we are server-side, we don't need to filter out the session data
            // See https://authjs.dev/getting-started/migrating-to-v5#authenticating-server-side
            // TODO: Taint the session data to prevent accidental leakage to the client
            // https://react.dev/reference/react/experimental_taintObjectReference
            async session(...args) {
                const session =
                // If the user defined a custom session callback, use that instead
                (await config.callbacks?.session?.(...args)) ?? {
                    ...args[0].session,
                    expires: args[0].session.expires?.toISOString?.() ??
                        args[0].session.expires,
                };
                const user = args[0].user ?? args[0].token;
                return { user, ...session };
            },
        },
    });
}

I did this change locally (that's why it's not on TS) and it's working as expected. The token is only refreshed on the middleware. Unfortunately I believe this is a problem we are not able to workaround in the client, it requires a change on next-auth. Here is the MR for the change: #11829