JWT Token refresh - getting outdated token to JWT callback

[marysmech]

I have implemented credentials provider (custom backend) with token rotation (based on https://next-auth.js.org/tutorials/refresh-token-rotation). Signin/Signout works nicely. When I call getServerSession I get everything correctly. Problem occurs when I need refresh access token. To be more specific refresh itself seems to be ok but new access/refresh token seems NOT be to stored se when I call getServerSession after refresh jwt callback seems to work with old data.

Example. After successfull sing in i have

{
  accessToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjljMTU2ZGY4NzA5NmFhYzJlYjI5YTVkZTU0NzQ3Mjg3ZDYxYTE0YmVkODRlNzUyMGQwODI0YWJhOTFkNDk5NjI0N2Y3ZGQ4YTBkYjY0MGY4In0.eyJhdWQiOiJYUXFKNll5ZVk3Y3JpNTM5UU5QRlNLRUlKR2ZBWThpYzFmUUMyQjR3ekxBIiwianRpIjoiOWMxNTZkZjg3MDk2YWFjMmViMjlhNWRlNTQ3NDcyODdkNjFhMTRiZWQ4NGU3NTIwZDA4MjRhYmE5MWQ0OTk2MjQ3ZjdkZDhhMGRiNjQwZjgiLCJpYXQiOjE2NzU3ODQwNTUsIm5iZiI6MTY3NTc4NDA1NSwiZXhwIjoxNjc1Nzg0MzU1LjIwMjk3MjksInN1YiI6IjMiLCJzY29wZSI6WyJhdXRoZW50aWNhdGVkIiwibmV4dF9jbGllbnQiXSwiaWQiOiIzIiwiZW1haWwiOiJ0ZXN0QHRlc3QuY3oiLCJ1c2VybmFtZSI6InRlc3QifQ.dxHGGDyzTSYFmmq9EQ7lxREhk_e1kwY7ektVzsHAzzuTo-zV8n7wOFhCChqIT1ib4WV55C-OQdZ5FyYd891OYJNMO76a7yvuts-rMGVIo-SaFZcg8YXYlKJXXM_jyPZ5s-RXGNL8DZ2OXGSmaj-LJM3isKtJDo0Jlpvz1H0ZE6Akq5Xi0bBD6mGPS77rszA97YTsvDsf4uVvePHSrz11R7JNxqkqI4V---WQoTscItd6QYRsobKpVgU2vtxUlpiWieg-2uiNe_K4WWbhpDg8IT5Ziwr5IRK2b5nWT2UlRdrlEGGVS3BNOZqw9Lfj5lRfBqEMIe3GKb5I9oVekfkUhg',
  accessTokenExpires: 1675784355386,
  refreshToken: 'def502003245a8b617e727ae234b6e50d0e44769a877d013e7c440fe46b8af73a593286efb064bd9daac3951157756277540dfc8102d4324a823253603ef2558be646929f736d71e83fa5ebdc75f02ba038d1f9bad63c3ac815ca83683c0f4506c2c37c5543d91298e3f86cdefcedac3781488e096601808aab97de32e6f2923ee1a37ec432fa51d69315b29991d16ce01010cb7d473008e3ccd79e3a46b92eb03566731875963e616a4ce8da952dabbb418d70338d2690bd0cb3b94ddd17480f67efea404a52ab7dba7dea035dfd244552954e606c0e3dfb0c5f4ff8e376cec2ee8b17316327ccc38319c264cf7902d560fa5647b0bbea5a5ea612d158bac51d954c15f632bdd213b58e24ec2a5aa4e5e998813a78f2ec94eb888a0a995ba65286f65d8c7c5896fd5705af7fc47bafc065ecef6d9f76e5c6b86566dbc4f807bab60a905452555bafa7d0fcf694fe581f9505dbbdbe24bd47922244bcfce4ec7885effc8d47e75b83dc1edb02b83b5841314cd559de4fa4b7beeb793b69cc1e3ddaa91a76dbcd84a2dcde916e5bde1422dfacce35df08cc7ffb9a5cfa0677d0034beb8a83c0ba69604e9',
  iat: 1675784055,
  exp: 1678376055,
  jti: 'df1afdff-33be-4b92-8b5c-55493c656991'
}

My JWT callback is almost identical to example from doc.

async jwt({ token, user }) {
      .....
      // Not expired
      if (Date.now() < token.accessTokenExpires) {
        return token
      }

      // Refresh token
      console.log('JWT REFRESH: ', token)
      return refreshAccessToken(token)
    },

If its token expired for first time its renew correctly. If I console log it after "refresh" and also in session callback there are new tokens:

{
  accessToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjUwMzFhNzI4YTIwZGYzZDYyYzYyM2E0ZGM2ZTAwNzhlMTA0OWJiYzgxY2JkNjRiMDNjOGVhNjBkZTNjNzY3ZDA2ZTc1MjA3NDkxMjg3YTQxIn0.eyJhdWQiOiJYUXFKNll5ZVk3Y3JpNTM5UU5QRlNLRUlKR2ZBWThpYzFmUUMyQjR3ekxBIiwianRpIjoiNTAzMWE3MjhhMjBkZjNkNjJjNjIzYTRkYzZlMDA3OGUxMDQ5YmJjODFjYmQ2NGIwM2M4ZWE2MGRlM2M3NjdkMDZlNzUyMDc0OTEyODdhNDEiLCJpYXQiOjE2NzU3ODQ0NzYsIm5iZiI6MTY3NTc4NDQ3NiwiZXhwIjoxNjc1Nzg0Nzc2LjcwNTgzOCwic3ViIjoiMyIsInNjb3BlIjpbImF1dGhlbnRpY2F0ZWQiLCJuZXh0X2NsaWVudCJdLCJpZCI6IjMiLCJlbWFpbCI6InRlc3RAdGVzdC5jeiIsInVzZXJuYW1lIjoidGVzdCJ9.tZtH2Asf_3PDjNvYTEDD-RwFjftD3uZT1ZRVUaesPp5XwkMWppsqTqDU69NhWGwLvm--Kzxu9G51LyslM8Z707d735hgT_-35UAwjyC2XxmfMVCMHO-YsUbyS3R50xuJyUjdOx4TFQemwBcSRPnEXpjzqf-kbPDE95j4rXn1wt3XfZEz59WBXXgzOaDhhBavPgadvg6Mr5bzVgulP8zUGUFz5c8z35BKnn-u5zOvMBikA6lqKLJerFKLFNyB1ZRueFfZRs1CIm3n5yFH7sC3wNcof2FRnSMuqlJ26eHcTj-w6ti1uRvZjCqMviQlrr80kMheU6LHjQLf2pDM-pzkcA',
  accessTokenExpires: 1675784776869,
  refreshToken: 'def502005fd5e09fe75fc7ddc2c6078191a14f3463f032ea09af9d074423e030040d728eb1f87be4a70c05d26f4bf6448a16352152a8545b98e7cdb3dcdae1ca93130e9c5ee230d07f2470f6a13f51c5faca56e525edd30a3972e25ddf5ce1a30467e7ba5737ea14c988e16f44f4c9cebdc15545a4313f6583497b8ffbcf43ffe65a8ea93934c89d45c3a52afd96dfaa6d656a17ed5c5604accb32c58d4a2060b22c5e791a30da232adf32746f228bd422d9e82ba95a409fbeb1d1d55ca62fe2fcabb1d44a1e5a6e74f7b0cfe571f8e668d0100f9c67eb8d51601b5b0d4bf4a0d2259383f8fb56d2eebcd188b0ac7a3ef58b74fb786a7f0cdddac83c81b317cb2ef06c721d9119affa159b6fffe09aee0574e85e22a998c518bf2e320a2a98052be919b9886b2e6530c2933da9af4f62e30b5785e36aebf033456eab05d09942edc48cc02a57d0f419f89bb098ba728913b8b629efb267f5ec11cb6ad6b416aa8d4f80607a88c24ac3dc11b86a51b6f9adaadfbb120fe58d4e11422b3ca753e0895b47299be1f856d4ba01745ebec59a73e36b4c83cd749a847b1aecdd409b6e0921c74895a2e18920e6',
  iat: 1675784055,
  exp: 1678376055,
  jti: 'df1afdff-33be-4b92-8b5c-55493c656991'
}

Tokens are different and everything seems to be ok. But if i call getServerSession once more its called refresh again and console log shows

JWT REFRESH:  {
  accessToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjljMTU2ZGY4NzA5NmFhYzJlYjI5YTVkZTU0NzQ3Mjg3ZDYxYTE0YmVkODRlNzUyMGQwODI0YWJhOTFkNDk5NjI0N2Y3ZGQ4YTBkYjY0MGY4In0.eyJhdWQiOiJYUXFKNll5ZVk3Y3JpNTM5UU5QRlNLRUlKR2ZBWThpYzFmUUMyQjR3ekxBIiwianRpIjoiOWMxNTZkZjg3MDk2YWFjMmViMjlhNWRlNTQ3NDcyODdkNjFhMTRiZWQ4NGU3NTIwZDA4MjRhYmE5MWQ0OTk2MjQ3ZjdkZDhhMGRiNjQwZjgiLCJpYXQiOjE2NzU3ODQwNTUsIm5iZiI6MTY3NTc4NDA1NSwiZXhwIjoxNjc1Nzg0MzU1LjIwMjk3MjksInN1YiI6IjMiLCJzY29wZSI6WyJhdXRoZW50aWNhdGVkIiwibmV4dF9jbGllbnQiXSwiaWQiOiIzIiwiZW1haWwiOiJ0ZXN0QHRlc3QuY3oiLCJ1c2VybmFtZSI6InRlc3QifQ.dxHGGDyzTSYFmmq9EQ7lxREhk_e1kwY7ektVzsHAzzuTo-zV8n7wOFhCChqIT1ib4WV55C-OQdZ5FyYd891OYJNMO76a7yvuts-rMGVIo-SaFZcg8YXYlKJXXM_jyPZ5s-RXGNL8DZ2OXGSmaj-LJM3isKtJDo0Jlpvz1H0ZE6Akq5Xi0bBD6mGPS77rszA97YTsvDsf4uVvePHSrz11R7JNxqkqI4V---WQoTscItd6QYRsobKpVgU2vtxUlpiWieg-2uiNe_K4WWbhpDg8IT5Ziwr5IRK2b5nWT2UlRdrlEGGVS3BNOZqw9Lfj5lRfBqEMIe3GKb5I9oVekfkUhg',
  accessTokenExpires: 1675784355386,
  refreshToken: 'def502003245a8b617e727ae234b6e50d0e44769a877d013e7c440fe46b8af73a593286efb064bd9daac3951157756277540dfc8102d4324a823253603ef2558be646929f736d71e83fa5ebdc75f02ba038d1f9bad63c3ac815ca83683c0f4506c2c37c5543d91298e3f86cdefcedac3781488e096601808aab97de32e6f2923ee1a37ec432fa51d69315b29991d16ce01010cb7d473008e3ccd79e3a46b92eb03566731875963e616a4ce8da952dabbb418d70338d2690bd0cb3b94ddd17480f67efea404a52ab7dba7dea035dfd244552954e606c0e3dfb0c5f4ff8e376cec2ee8b17316327ccc38319c264cf7902d560fa5647b0bbea5a5ea612d158bac51d954c15f632bdd213b58e24ec2a5aa4e5e998813a78f2ec94eb888a0a995ba65286f65d8c7c5896fd5705af7fc47bafc065ecef6d9f76e5c6b86566dbc4f807bab60a905452555bafa7d0fcf694fe581f9505dbbdbe24bd47922244bcfce4ec7885effc8d47e75b83dc1edb02b83b5841314cd559de4fa4b7beeb793b69cc1e3ddaa91a76dbcd84a2dcde916e5bde1422dfacce35df08cc7ffb9a5cfa0677d0034beb8a83c0ba69604e9',
  iat: 1675784055,
  exp: 1678376055,
  jti: 'df1afdff-33be-4b92-8b5c-55493c656991'
}

As you can see there seems to be same tokens and everything like it was after sing in. And newly obtained tokes from refresh disappeared somehow. I have tried it multiple times but results is always the same. Does anybody knows what am i doing wrong? I read documentation and searched for issues and I found nothing.

I use nextjs 13.1.6 and next auth 4.19.2.

Any help would be appreciated.

[marysmech]

Problem seem to be similar to #371 (comment) and according this comment

If you make changes to the token in the jwt callback, they should be persisted in the JSON Web Token (i.e. whatever is returned from it should be saved back to the token).

all of my changes are done in jwt callback but still changes are not persisted.

[PedroLucasSilva]

I am facing the same issue :(

[osmandvc]

Is there a solution to this? Using exactly the same and having the same problem.

[matthewpavia99]

Did anyone manage? Experiencing exactly the same issue

[mrbodich]

Have the same issue, next-auth 4.22.1, nextjs 13.4.2. Keycloak as IDP.
Created a bug report here #7558, then got the link to your question in comments...

[dever23b]

I don't have a solution yet, but I believe this problem relates to the same issue noted here regarding only having read-only access to the session cookie when using the app/ directory.

In my case, I can refresh successfully for the duration of the session; however, if I refresh the page, I get the same symptom you're dealing with. The issue is that, while the refresh process works and the jwt callback returns a new token payload properly, it only persists in memory because that payload doesn't get saved to the cookie. So, when the page is refreshed, an old payload (and associated refresh token) is retrieved from the cookie and presents this symptom.

[diegotc86]

I have the same problem and this is the most concise explanation I've read so far. This is a dealbreaker for me.
Could using a different auth library like iron-session be a solution?

[itsbetma]

Same problem here!

[gidgudgod]

same problem and still not yet found any solution

[AdisonCavani]

You are facing the same problem as #7522.

It's probably going to be resolved in a new major version.
See this PR: #7443.

I received a comment from Next.js team member about adding API for writing cookies in RSC (since currently it's read-only):

Thanks for the feedback, the team is aware

[thexpand]

Thanks for the PR reference. I went through the changes there but couldn't find how they solve it exactly. I believe that's a general problem in how Next 13 works with RSC. Are there any workarounds until that one's resolved? At least if we knew how they would be resolving this issue, we would know on what workaround to find by then.

[AdisonCavani]

Maybe by the time this PR is merged and released Next.js team will improve the cookie API

[hobadams]

Has anyone tried updating to v5 to see if it fixes the issue? I had a quick look but I was met with a bunch of errors so I need to invest a little more time into it. How are people getting around it at the moment?

[robotpapier]

Hi, same issue in Sveltekit with

• "@sveltejs/kit": "^1.20.0
• "@auth/core": "^0.8.1"
• "@auth/sveltekit": "^0.3.1"

[amil-m]

I am facing the same problem with "@auth/core": "^0.8.2"

[Cikmo]

Yeah. Same here. Did you ever find a workaround?

[rohanrajpal]

+1, did anyone find a workaround?

[hobadams]

Hey everyone. Any updates on this? Thanks @dever23b for the very clear explanation.

I'm using Auth0 and without a fix i'm going to have to set the access_token to longer than i'd like.

[dever23b]

This issue is set to be resolved in the next major release. It's not easy to dig up the comment from my phone, but if you track the issue you'll find a post from the dev confirming this.

You can therefore track updates in PR #7443, which is currently in experimental status.

[dimbslmh]

next-auth/packages/next-auth/src/react/index.tsx

Lines 161 to 167 in a79774f

	export async function getSession(params?: GetSessionParams) {
	const session = await fetchData<Session>(
	"session",
	__NEXTAUTH,
	logger,
	params
	)

next-auth/packages/next-auth/src/react/index.tsx

Lines 474 to 478 in a79774f

	const newSession = await fetchData<Session>(
	"session",
	__NEXTAUTH,
	logger,
	{ req: { body: { csrfToken: await getCsrfToken(), data } } }

Looking at how useSession().update works.. getSession() requires the CSRF Token to return the updated session.

getSession({ req: { body: { csrfToken: await getCsrfToken() } } })

Note: It only updates the token of the first async call.

[AsgrimS]

I'm having the same issue using:

"@auth/core": "^0.9.0",
"@auth/sveltekit": "^0.3.5",

The new token is passed correctly to the session callback, but it is not updated for the jwt callback so it triggers refreshToken logic every time after the initial expiration.

[rads92stx]

Having the same issue

[ahbouzidi]

getServerSession() solve the problem for me, here is an example how to get the session on client side (just pass the session in the props and you are fine)

import { GetServerSideProps } from 'next';
import { getServerSession } from 'next-auth';
import { authOptions } from '@/pages/api/auth/[...nextauth]';
import useRefreshTokenError from '@/hooks/useRefreshTokenError';
import React from 'react';

export default function Home({ error }: { error: string | null }) {
  useRefreshTokenError(error);
  return <span className="title-box">Welcome</span>;
}

export const getServerSideProps: GetServerSideProps = async (context) => {
  const session = await getServerSession(context.req, context.res, authOptions);

  if (!session) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
      },
    };
  }

  const error = (session as any)?.error;

  return {
    props: {
      error: error || null,
    },
  };
};

[dever23b]

Unfortunately, this issue revolves around the use of the App Router. If you're still using the pages/ system, this issue doesn't present. Thanks though.

[muhammadali-pro]

I was facing similar issue.

This is how i Fixed it.

callbacks: {
    async jwt({ token, user}: any) {
      if (user) { 
        //expires : my custom attribute for token expiry
        const data = {...token, ...user, ...expires};
        console.log(`When Log in`);
        return {...data}
      }
      
      //means this time it is not called due to login
      const aExpiry = token.accessExpiry;
      const now = new Date().getTime() /1000; // time now
      if (now < (aExpiry - 300)) { //300 means 5 minutes
        console.log(`Access Token Not Expired`);
        return {...token};
      }
      
      // means access token is expired
      const rExpiry = token.refreshExpiry;
      if (now < rExpiry - 300) {
        console.log(`Access Token Expired`);
        // if atoken is expired
        const data = await getRefreshedTokens(token.refreshToken);  // mys custom function for calling backend API for refreshing tokens
        if (data.status == 200) {
          console.log(`tokens refreshed : ${JSON.stringify(data)}`);
          return {...data};  //this was mistake
        }

        console.log(`error refreshing tokens`);
        return { ...token, error: "RefreshAccessTokenError" };
      }


      console.log(`Refresh token expired`);
        return { ...token, error: "RefreshAccessTokenError" };
    },

    async session({ session, token,user }) {
      session.user = token as any;
      return session;
    },
  },

The issue that i had in my code was that i was returning new tokens without including previous token properties.

so i changed

from this
return {...data}

to this
return {...token, access_Token: new_access_token, refreshToken: new_refresh_token, ...expires}

so when you return your new tokens, don't just send back new tokens. also include ...token (previous token that we get from jwt props)

[dever23b]

From my experience, this code will only work on the old Pages router. The issue we're having is that, on App Router, we can't yet change the data stored in the JWT once it's created. It fails silently, so it appears to work initially; however, the refreshed tokens are not persisted. The next time the JWT cookie is read, the original(/invalidated) tokens are used leading to auth failure.

[muhammadali-pro]

Just for your information, i am using app router, next.js 13.4, next auth, and a custom backend API with next auth credentials provider. I am trying to refresh my tokens when my access token gets expired. So my Backend API gives back both new access token and new refresh token. I was able to refresh my token multiple times without any issue. it is working. can you explain to me what i am doing wrong? I mean is there anything that i am missing ?

[dever23b]

Sorry, I didn't mean to suggest that you were doing something wrong at all. In fact, if that works for you, congratulations! I've written something similar that, functionally, does the same thing as your example and I ran into the same issue many others are facing. In my experience, since the JWT cookie write silently fails, the refresh process appeared to work seamlessly while the most recent tokens were available in memory. However, once the cookie was re-read (page refresh, for example), the whole thing fell apart because the cookie wasn't ever being (over)written successfully.

Every variation I've done on manipulating the JWT callback has had the same result: the initial data for the cookie during logon is written successfully; however, changes to the JWT payload on subsequent executions of the JWT callback silently fails to write.

We were told by the dev that this is being addressed in v5, so I think many of us experiencing this issue are patiently waiting. If your solution is working in your environment, that's great news.

[aliyss]

I documented some stuff here: #7558 (comment)

[jawaad-juggle]

I'm also getting the same issue. I switched over to the experimental version and still facing the same problem. Unless I've configured it wrong :(. Has anyone else had any luck with this as yet?

[jawaad-juggle]

@balazsorban44 Would you be able to shed some light on this issue?

[Kuzmich100kM]

I have implemented credentials provider (custom backend) with token rotation (based on https://next-auth.js.org/tutorials/refresh-token-rotation). Signin/Signout works nicely. When I call getServerSession I get everything correctly. Problem occurs when I need refresh access token. To be more specific refresh itself seems to be ok but new access/refresh token seems NOT be to stored se when I call getServerSession after refresh jwt callback seems to work with old data. ...

Similar problem.
Credentials, Updating tokens from DB -> Replacing tokens in callbacks iwt(), session(). If the APP does not have getServerSession(), then through f5 everything is updated normally many times. The first adding to code getServerSession() calls refreshTokens() twice in a row: the first normally updates the session with tokens, and in second - has a previous refresh token refresh.
I spent several days testing and searching for errors until I found a similar problem here, but I still didn’t see a solution. If someone has decided, tell me where to look, please.

[muhammadali-pro]

I had a working example but as @dever23b said earlier, now i am facing same issue. Still I am unable to find any solution.

[abbashyder]

Hey Folks! Do we register an issue for this as this discussion here doesn't seem to be getting traction? I just completed auth with the credentials provider and landed here after a few hours of debugging when my access token would always require to be refreshed after the first expiry. Happy to provide steps to reproduce and other details.

[aid982]

I am using "next-auth": "^4.23.2","next": "13.5.4", facing same issue

[vulebaolong]

I also have the same problem, may have to wait for the next update. I'm looking for an alternative, if anyone has an alternative, please share with me

[hobadams]

I'm seeing the same issue using the Auth0 provider. I'm testing using the latest Next auth demo app (next-auth 5.0.0-beta.3) + Next.js v14.0.3 .

In my browser I can see the session cookie value and lifetime is actually updating when refreshing the browser but if i log auth inside an app/api/route.ts file it's not updating. Likewise if i log the access_token in the jwt() callback it's not being updated. It seems like there is a disconnect between the middleware, server session and browser / cookie.

If anyone has a solution to this it would be much appreciated.

For context my app uses a JWT to form an auth header, we add this to requests to a custom BE that checks them against Auth0. Seems like a pretty standard use case.

[toivanenmiika]

I'm doing this in middleware.ts and for me it seems to be working:

const sessionCookie = process.env.NEXTAUTH_URL?.startsWith('https://')
  ? '__Secure-next-auth.session-token'
  : 'next-auth.session-token';

if (YOUR TOKEN EXPIRE CONDITION) {
    const newToken = await refreshAccessToken(session); // You'll need to implement your custom token refresh logic
    const newSessionToken = await encode({
      secret: YOUR_NEXTAUTH_SECRET,
      token: {
        ...session,
        ...newToken,
      },
      maxAge: MAX_AGE_IN_MS,
    });

    response.cookies.set(sessionCookie, newSessionToken);

    return response;

[hobadams]

Thank you. And is this using next auth 5.x?

Previous versions of next auth allowed the middleware to be overridden using withAuth. This doesn't seem to exist in v5. Any ideas?

Thanks

[toivanenmiika]

This is in 4.x.x as v5 is still in beta. Looking at the v5 docs / examples (https://authjs.dev/reference/nextjs#example-7) I think it is possible to replace withAuth with auth. I'll probably migrate to v5 after it becomes stable.

[hobadams]

I'll give it a try and let you know how i get on.

[hobadams]

Unfortunately next-auth/jwt is deprecated in v5 so I'm not sure how to get the encode method. Does anyone have any ideas?

[Kiranism]

Ah, it seems to be a major bug. Has anyone found a workaround for this?

[hudovich-dev]

This is still an issue...

[ApinisMikelis]

Please god help us

[desiboli]

😆

[MarkMurphy37]

This is exactly how I feel 😂

[wppaing]

I fixed this by making exp 1 month😂

[mohammedsafvan]

anyone resolved the issue?

[muhammadali-pro]

I have done same thing for now but i hope so we will get a fix for that.

[DaviLhlapak]

I have my own backend with JWT and credentials sign-in, and this issue directly affects my workflow. I think they are no longer focusing on this package since they are updating auth.js, which, in my opinion, is not a wise choice when it comes to authentication, opting for a multiplatform library.

Based on that, I learned more about the next-auth package and created my own library implementing the next-auth JWT functions. I believe the result is excellent; I'm using it in my project, and the middleware in Next.js is very effective in handling sessions.

If someone has the knowledge to open a pull request to next-auth, fixing the middleware part, I think this will solve your problems. For now, I'm sharing my public package for your review and use if needed.

https://github.com/AlpakasLab/nextjs-jwt-auth

[aliyss]

#7558 (comment)

In case anyone wants to give this thread a look. I think I added some meaningful comments.

[ryanwi]

After several hours of trying to figure out what I was doing wrong, I'm at least relieved to find this discussion and learn that it's a bug. Same problem where the refresh logic is working, but the old token is still the one loaded on the next request.

async jwt({ token, account, user, trigger }) {
  console.log("jwt", token, account, user, trigger);

  if (account && user) {
    // Persist the OAuth access_token and or the user id to the token right after signin
    return {
      id: user.id,
      email: user.email,
      accessToken: account.access_token,
      expiresAt: Math.floor(Date.now() / 1000 + account.expires_in),
      refreshToken: account.refresh_token,
    }
  } else {
    // if this is an existing user, nothing we do here get's peristed past this request
    return {
      whatever: "you want"
    };
  }

[karlbessette]

I found out that the session wasn't updating after an api request. After digging a lot, I've found this:

import { useSession } from 'next-auth/react';
const { update } = useSession();
update()

Call update() in your client after making the API call and it'll sync the backend session with your cookies and you'll now have the new AccessToken and RefreshToken.

Now I have to figure out a way to call update after each API request.

[hobadams]

Wow, thanks for the share. I might try to give this a go next week. If i get any closer to a solution i'll be sure to share

[ssolders]

Hi, we've run into the same issue. We're using Next12 with page router and a custom _app.tsx.
We had a thought that it might be a race-condition issue which lead us to try out a hacky way to get around this.

Some comments have mentioned that the getServerSession works as expected but the "client ones" does not. But since we use a custom app with _app.tsx we've resolved to use getSession when fetching the session server side. We also fetch the session using the getSession in our api-fetch util that append the token to our requests. We suspect that this creates the race condition.

We added a sleep() that waits 10ms before calling getSession() (serverside) and were able to refresh our token and get an updated value persisted in the jwt.

Obviously this is not an ideal solution but perhaps it can help someone with better insight in this issue.

The sleep utils is just a simple wait promise

const sleep = (duration: number) =>
  new Promise((resolve) => {
    setTimeout(resolve, duration);
  });

In our _app.tsx

OurSite.getInitialProps = wrapper.getInitialAppProps((store) => async (appContext) => {
  const props = await App.getInitialProps(appContext);
  const req = appContext.ctx.req

  await sleep(10);
  const session = await getSession(appContext.ctx);

Our [...nextAuth].ts follows the docs, nothing special there, can share if needed.

[NanningR]

@aliyss @ryanwi @karlbessette @ssolders @ApinisMikelis @desiboli @MarkMurphy37 @wppaing @mohammedsafvan @muhammadali-pro

For anyone still wondering, workarounds / temporary solutions are available here: #9715 (hats off to the guy Rinvii who first came up with it). See my comment: #9715 (reply in thread).

[ssolders]

Thank you! Rinvii's solution worked for us!