How to manually trigger next-auth to refresh the JWT?

[MaxRandle]

Hi Devs,

I have a situation where the user can update their personal details and some of those details are also used to make up the payload of the JWT that is generated by the server. Therefore an action performed by the client can actually cause the token to contain stale data. I have been provided with an endpoint that will regenerate a new token on the serverside and return it to the client. So I would be able to hit this endpoint and get a new token after the user updates their details in this way. My question is how can I get next-auth to accept a new token and start using it for the current and subsequent sessions? I've already read through #371 but I've not seen a solution that will deliver the right behaviour in my case.

Some additional info:
I am aware of the jwt() callback that you can supply to next-auth, here's my understanding of how it works:

• A token returned by the jwt() callback will be saved by next-auth for use in the current and subsequent sessions. (I assume that this would probably provide the behaviour I'm looking for if I could get jwt() to return the new token)

• The jwt() callback fires each time a call to getSession() hook is made, so it could be triggered manually by making use of that hook.

Even though next-auth has provided a way to get the jwt() callback to fire on command, it seems like I don't have a way to get control over the arguments passed to the jwt() callback. Therefore I don't see how I would be able to write any logic inside this callback to return a new token even if the token has not expired and is still valid etc.

See below from the docs (I've inserted some comments to highlight my problem)

  callbacks: {
    async signIn({ user, account, profile, email, credentials }) {
      return true
    },
    async redirect({ url, baseUrl }) {
      return baseUrl
    },
    async session({ session, user, token }) {
      return session
    },
    async jwt({ token, user, account, profile, isNewUser }) {

      // if token is expired
      if (token.expiresAt > new Date()) {
         // regenerate and return new token
      }

      // no control over the arguments passed here
      // can't write logic here to regenerate token on command even if its not expired.

      return token
    }

If anyone could point me in the right direction that would be a massive help, I'm not sure where to look at this point. I'm also not sure if the operation that I'm attempting to describe has a name (session mutation?) so even pointing me at some similar questions or threads that solve my issue under a different name would be great. Please ask me to clarify if I haven't provided enough of an explanation.

Cheers.

[rafde]

@MaxRandle did you also take a look at https://next-auth.js.org/tutorials/refresh-token-rotation ?

[MaxRandle]

Hi rafde,

Yes I have. From my understanding that only demonstrates how to renew a token if it has expired, what I want is to be able to renew it on demand. Unless I'm missing something?

Cheers,

[toomus]

I have similar problem, and there is no working solution anywhere. So i had to make my own.
I have JWT coming in api response, and I want next-auth to create session with this token, so user will be auto logged in.
All you have to do is create another credentials provider with unique id (if you have more than one credentials provider), which will be just pass data further to callbacks.

eg.

Providers.Credentials({
  id: 'direct_jwt_auth',
  credentials: {},
  async authorize(credentials: DirectJwtAuthParams): Promise<WithAdditionalParams<User>> {
    const { id, email, token } = credentials;

    return {
      id: id,
      email: email,
      token: token,
    };
  },
})

Then in view where you receive api response you can do

await signIn('direct_jwt_auth', {
  redirect: true,
  callbackUrl: 'http://localhost:3000',
  id: apiResponse.id,
  email: apiResponse.email,
  token: apiResponse.token,
});

And voila user is signed in :)

[archercoder]

hi @toomus, I have the same goal as MaxRandle that I want to update existing session param with the new value based on user action, let say user launch verify email link and system will replace the email_verified param in session from false to true. As my understanding from the doc, by updating jwt will updates the session too.
May I know with your solution, what will happen to the previous token and its session ? Are they being replaced with the new sign in payload ?

[1finedev]

This is a major issue and there are so many duplicate issues asking how to manually update a signed in user object data but no response so far...

[toomus]

Every call to signIn overrides previous values

[sabres207]

@toomus but it also involving the user, I'd love an option to force refresh of the token without involving the user

[MaxRandle]

Bump on this issue. Our team still doesn't have a solution barring doing something potentially unsafe or hacky like trying to set the HttpOnly session cookie ourselves.

[smithmilner]

As a workaround to this I added a new CredentialProvider to my setup which simply takes the accessToken of the currently logged in user along with anything I need to alter the session. In my case I have an address form.

Then in the submission of the address form I simply call signIn('update-account, { accessToken, newAddress, redirect: false }) and it will update the token..

A bit hacky but it works.

[MaxRandle]

Hi @smithmilner

This has actually been suggested to us as the best current solution to this problem. We tested this a few months ago and unfortunately it causes our app to reload which would create other problems we would then need to solve and in any case we don't want our users to have that experience. I'd be interested to hear if you have similar behaviour and how you are dealing with it.

[smithmilner]

Oh interesting. I'm not seeing a page reload, it works nicely. But I did disable the redirect. https://next-auth.js.org/getting-started/client#using-the-redirect-false-option

Updated my above example to show that.

[CiroAngeleri]

@toomus Solution worked for me with a little tweak:

    CredentialsProvider({
      id: 'update-user',
      credentials: {},
      authorize(credentials) {
        return { user: JSON.parse(credentials.user) };
      },
    }),
    
    ...

    await signIn('update-user', {
      user: JSON.stringify({ ...user, newProperty: true }),
    });

Seems that when passing objects you need to serialize them as strings with JSON parse/stringify

[maltesa]

You can either use a custom jwt encode, decode functions or import the one used by nextauth. I'm using a custom one.

[rmptf]

Ah yes that makes sense, I didn't realize getToken() can decode as well until you pointed it out.
Thankyou!

If you don't mind, I have another question.
How did you programmatically call signIn() with credentials from server side?
something like a POST req to /api/auth/callback/update-signin ?

[maltesa]

I'm not sure if signIn is meant to be called server-side. I'm calling it on the client:

export default function Settings() {
  const router = useRouter()

  useEffect(() => {
    if (router.query.action !== 'refresh') return

    // Refresh session to reload user data (activePlan may have changed due to subscription changes)
    const refreshSessionAndReload = async () => {
      await signIn('jwt', { redirect: false })
      router.push(router.pathname)
    }

    refreshSessionAndReload()
  }, [router])

  return // ...
}

Users are redirect from stripe checkout to /user/settings?action=refresh. This way, I ensure, that changes due to a checkout are reflected.

I guess your idea is to refresh the session directly on the server-side in the stripe webhook (for example). This would not work for me as I'm using the jwt strategy. Calling signIn server-side would not update the JWT on the client. If you use the database session strategy, this may work. Though, I guess it may leave the client with an invalid session. I can't tell since I don't know how the database session strategy works.

[rmptf]

Thanks maltesa! Your help has been much appreciated. got it working.
You were right, and in the end I had no need to call it from the server if I just make a post request to my DB then call signin() from there.

[JorjeRedemption]

Great solution! Works great so far! I have implemented a version of your method here @maltesa - thank you for that!!

However, I did hit a bit of a roadblock when trying to test this behind SSL - which will obviously need to happen when deploying to production - the jwt signIn endpoint just returned a 401 response with the following content {"url":"https://mytestdomain.io/api/auth/error?error=CredentialsSignin&provider=jwt"}

What fixed that for me was changing the line that parses the cookie to include the __Secure- prefix - now it works perfectly! Just in case anyone else stumbles across this.

const token = cookies['__Secure-next-auth.session-token']

Until we see some kind of solution to this issue implemented in NextAuth, this method will have do for us. Thanks again everyone!

[MaxRandle]

A few people have suggested creating an additional custom credential provider that accepts the old token, then calling signIn for the new provider. This is a good solution and I encourage you to try it for yourself if you have a similar issue.

Unfortunately it may not provide the behaviour you want because calling signIn invalidates the session and causes all hooks and pages that have a dependency on session to refetch all their data (which also affects everything rendered inside <SessionProvider>) even when setting redirect: false in the signIn options. This was the issue in my case. This is a terrible experience for the user and introduces way too much jank.

I'm tempted to mark this as the solution because the longer I think about the more this starts to sound like expected behaviour. However Ideally I'd like someone from the NextAuth team to endorse this as the accepted solution or suggest a better way because ultimately this is a hack.

The solution I want is to be able to control arguments or options passed to the jwt() callback. I want to be able to call getSession or useSession and pass options or arguments that make it to the jwt callback where I can consume them and write some login to return a new token.

Some example code of how this could look:

useSession call

useSession({ jwtOptions: { refresh: true })

jwt callback

async jwt({ token, user, account, profile, isNewUser, jwtOptions: { refresh } }) {
  // if token is expired
  if (token.expiresAt > new Date()) {
    // regenerate and return new token
  }

  // if manual refresh
  if (refresh) {
    // regenerate and return new token
  }

  return token;
}

This way I can just manually refetch any data that could have changed as a result of the session updating.

This is dead simple and I'm convinced it would provide the right behaviour as well as being easy to implement.

[MaxRandle]

Yes probably. It's more in line with how hooks are meant to be consumed.

[IDrumsey]

@balazsorban44 @iaincollins any thoughts on this?

[Chamberlainfrancis]

Truly, calling signIn() invalidates the session; all hooks and pages that depend on the session will have to re-fetch their data.

But the end user shouldn't feel the impact because everything will update in the background asynchronously without the user reloading or having any bad experience on the page. If the behavior is different on your end, you must check how you handle your JWT accessToken on your Backend/API.

Overall, there should be a next-auth way to handle this better and I'm hoping they will come up with something.

[selenecodes]

Is there any update on this?

[LookLukeLemon]

any update here?

[zenflow]

Is there an issue for this?

[iakovosvo]

Should we convert this discussion into an issue so that it gets more visibility? It seems to be the most upvoted discussion topic and a lot of people need this feature.

[zenflow]

If there isn't an issue already, then definitely. This is only visible as a discussion, and looks (at a glance) more like a discussion on how to do something rather than a discussion on an issue. We should have a record of the issue in Issues.

[iakovosvo]

Alright, I just opened a new issue that has the description from @MaxRandle and a link to this discussion.

[emroot]

It would be great if there was a method on the server like
updateToken(req, { ...user, newValue: ...}) which will automatically pass the new jwt value back to the client and voila.
In my case I would use this after a user updates their profile.
Not sure if that's a security hole or not

[emroot]

it's call on my api, when a user updates their profile, I update the token with the new info.

[AllenWilliamson]

Thank you for providing this snippet @emroot. How are you exporting cookies and MaxAge from ../pages/api/auth/[...nextauth]?

[emroot]

those are just constants with my own cookie and maxAge def.
https://next-auth.js.org/configuration/options#cookies

[kodobrody]

@emroot could you share your cookies object possibly?

[AllenWilliamson]

@kodobrody After playing around with it myself, I ended up copying the defaultCookies function from https://github.com/nextauthjs/next-auth/blob/main/packages/next-auth/src/core/lib/cookie.ts.
In my [...nextauth].ts I export the cookies and use them in authOptions.

import { defaultCookies } from './cookies';

export const cookies = defaultCookies(false);

export const authOptions: NextAuthOptions = {
    /* typical auth options */
   cookies,
}

MaxAge is just a number you could extract out from defaultCookies as well.

[atomcat1978]

Unfortunately - after a week of struggle - it seems to me like token refresh is not really supported in this framework. The token might be refreshed by either a server side call that pings the session (such as unstable_getServerSession) or by the client (by using getSession for example). The problem is that if the server side refreshes the token, this fact is not populated to the client, and then the client fails by the next getSession call, since both, the refresh and the access token it sits on are out of sync.

As I see, unstable_getServerSession sets the cookies, however, it is not picked up by the client. Possibly this could be solved by a cookie change listener, however, this API is still experimental:(

Anyways, at the current state it is very-very hard to get to a consistent client with token rotation, and the problem mentioned originally is also a blocker to have at least some kind of workaround.

[matthewpavkov]

You can make it work. In the jwt callback, you're either returning the original token (from when the user logged in) or you're returning the refreshed token. In either case, the client will have the correct token.

Something like this:

async jwt({ token, account, profile, user }) {
  if (account) {
    token.accessToken = account.access_token;
    token.refreshToken = account.refresh_token;
    token.accessTokenExpiration = account.expires_at * 1000;
  }

  // Return previous token if not time to refresh
  if (Date.now() + (5 * 60 * 1000) <= token.accessTokenExpiration) {
    return token;
  }

  // Time to refresh access token
  return refreshAccessToken(token);
}

And the refresh:

async function refreshAccessToken(token: JWT) {
  try {
    const response = await fetch(url, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Authorization': 'Basic ' + encodedAuth
      }
    });

    const refreshedTokens = await response.json();

    return {
      ...token,
      accessToken: refreshedTokens.access_token,
      accessTokenExpiration: Date.now() + refreshedTokens.expires_in * 1000,
    };
  } catch (error) {
    return {
      ...token
    };
  }
}

And then client side I'm polling the session every so often. I'm using the token as a bearer, so I have to rotate that manually, but I'm not doing anything to update or influence NextAuth - from what I can tell, it does indeed have the updated access token.

getSession().then((response) => {
  // Token, etc., are now updated: response.accessToken, response.user
});

I never think about or touch the cookies. Subsequent calls to useSession work as expected. Of course maybe I'm missing something here, but this is working for me.

[ayalon]

@atomcat1978 I have exactly the same issue, that the token is refreshed server side but the client / browser has still the same old cookie.
Ant then happens exactly what you describe.
Did you find a way to solve . The above rotation code does not work because after the page reload I still get the same old cookie as you described.

[atomcat1978]

@ayalon Yes, at the end, today. What I do is that on the client side a popup is shown when access token timeout is getting close (5 minutes currently). If the user pushes on the still here button, i do a forced refresh of the session on the server side by sending in a forceRefresh=true query parameter.

NextAuth handler was modified to be able to handle the parameter by making nextAuthConfig into a lambda, that takes som config params, and so returns the config:

type CallbackOptions = {
  forceRefresh: boolean|undefined;
}

export const authOptions: (callbackOptions: CallbackOptions) => NextAuthOptions = (callbackOptions) => ({
/*...*/
// later on the param can be used in the JWT callback to force-refresh the token:
    async jwt({account, token}: { account?: Account | null, token: JWT }): Promise<JWT> {
      // initial log-in
      if (account != null && token != null) {
        enhanceToken(token, account);
        return token;
      } else {
        const currentAccessSecRemaining = (token.accessTokenExpires - Date.now()) / 1000;
        const expired = currentAccessSecRemaining < ACCESS_TOKEN_MINIMUM_SEC_REMAINING;
        if (expired || callbackOptions.forceRefresh) {
          logger.info("Token has expired/force refresh, refreshing.");
          return await refreshAccessToken(token);
        }
        logger.debug("Token still valid, no refresh needed.")
        return token;
      }
    },

Than the only thing is to handle the query parameter:

const middleware = async (req: NextApiRequest, res: NextApiResponse) => {
  return NextAuth(req, res, authOptions({ forceRefresh: req.query.forceRefresh === "true" }));
}

export default middleware;

Than the only thing to do on the client side is to create a small infrastructure that takes care of showing the model, and than the handler on the button:

  const renewSession= async () => {
    await fetch("/api/auth/session?forceRefresh=true");
    setDisplayTimeoutWarning(false);
  }

[skwowet]

I think this is the very same problem I have, opened a discussion couple of days back: #6489

[pixeliner]

Why would you want to update the refresh token?
It should be the accessToken.

The refreshToken is something you set for a day to a week, that token is used to keep people logged in during its lifetime.
The accessToken should be updated every time it expires using some /refresh endpoint. The refreshToken itself shouldn't be altered.

[skwowet]

Because we're trying to implement refresh token rotation something like this suggested by auth0: https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation

Could you please clarify with what we're doing wrong? is something not recommended?

[MrBond2104]

I also experience this client side issues for the token rotation. The callback is only triggered on page refreh. So the access token on the client can get invalid in runtime. Opened a own discussion #6412

[akd-io]

Also facing this issue with a NextAuth + Cognito integration.

Cognito supports custom attributes which we are using to store additional info necessary to connect to a backend API. But as it isn't possible to manually refresh these tokens, users have to log out and in again to get the updated token. We'll be adding an additional fetch request to get the info from a backend API instead for now.

[rolanday]

There are many threads and issues posted on this topic, and for quite some time with no action. I'm afraid I've reached the point where I'm going to start down path of implementing OAUTH flow on my own because while auth.js a great effort from great people in their spare time, I'm sure, it's not useful for for anything other than hobby projects when missing basic functionality like the issue posted here (i.e., being able to initiate jwt and session callbacks being called from the client). It's a non-starter that the user should need to log-in/out or refresh the page because they, for example, changed their user handle (or some other prop that app decides to attach to jwt) which need to be reflected in updated session state.

[emroot]

check this comment.
#4229 (reply in thread)
you can update your session cookie with your updated info

[rolanday]

Thanks @emroot , seems like a reasonable workaround. Does the call result is session state getting update in session context provider? For my app, I set token in jwt callback, which is called before session callback in nextauth config. Regardless, I'm going to roll my own using same openid_client next auth uses, because I'm using auth.js just for authentication, and not taking advantage of other features like db adapters or auth0, so I'm spending more time working around authjs than makes sense for me.

[ayalon]

I was able to fix the issue in the Nuxt Auth implementation here:
sidebase/nuxt-auth#200

I think exactly the same step needs to be fixed on the server side request with NextJS.

Here is the function "getSession()" called:

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

Line 361 in 326eadf

__NEXTAUTH._session = await getSession({

Inside this function a fetch is made to the server/auth/session endpoint and the header should contain the new setCookie header. This header has to be transfered to the server side requests to update the cookie correctly. Else the setCookie only applies to the fetch request.

I don't know how to fix it in NextJs but I was able to get it working in Nuxt. You somehow need to update the server side context and copy over the cookie header.

[AlecKriebel]

For those that stumble upon this in the future, here's my partial-solution (for a Next.js web app using NextAuth & Prisma)

Use case:

allow a user to update information on their "profile"/"user", in this case the user's name

Problem:

"name" is stored inside my JWT, and after updating the user within the database, the JWT is not updated, causing frontends to display out of date "names"

Solution:

Use the session callback to modify calls to getServerSession ( or GET /api/auth/session) to pull latest information from the DB. Here's the backend source for getting a JWT session.

In my NextAuthOptions:

callbacks: {
    session: async ({ session, token }) => {
      // NOTE: this is only necessary because this is the ONLY point where
      // new info from the DB is pulled into the JWT, if there is any
      // ideally, there would be a separate refresh endpoint, but NextAuth doesn't yet have one.
      // If there is one, remove this since it adds 1 query to every API call
      const user = await prisma.user.findUnique({
        where: {
          id: token.sub,
        },
      });

      return {
        ...session,
        user: {
          ...session.user,
          name: user?.name,
          id: token.sub,
        },
      };
    },

Then, you can call getServerSession() in backend API's that update information in your JWT to send back an updated cookie in that response's header.

In the frontend, you can call getSession() to pull the updated JWT too.

Note: Either method may need a hard refresh of a frontend client to update the SessionProvider if you're using one (I'd love to know if there is a way to update session in SessionProvider without a refresh if there is one!).

Caveats:

This is inefficient and will produce 1 additional query to your database on every session validation or fetch.

The ideal solution is to have a separate "refresh" or "revalidate" JWT API, but this is not supported out of the box now from what I can tell. Creating a new provider is a way to achieve this as suggested above, but I'd rather not be manually managing these things myself.

[trollbot38]

Is there a solution? Seems like none and everyone rolling their own secure or insecure. No workaround due to concerns of unideal or unsafe probably only makes everyone implement worse security.

[pbell23]

Any update on this issue ?
Have to use a separate api call to handle updated user informations for now.

Edit:

I found a solution working for my case, here is the code :

On the frontend, create a refresh function :

const refreshSession = async () => {
  await fetch("/api/auth/session?refresh=true", {
    method: "GET",
    headers: { "Content-Type": "application/json" },
  });
  await signIn('email', { redirect: false });
}

First call will get the session through the API. This triggers jwt and session callbacks. I add a refresh param to differenciate the call.

Then, in my jwt callback (or session callback depending on your configuration/needs):

async jwt({ token, user, isNewUser }) {
      if (req.query.refresh) {
          const refreshedUser = await getUserById(token.user.id) // refresh user from db or whatever you need
          token.user = refreshedUser
      }
      return token;
}

Also updating in the session callback :

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

Finally, the last call on the frontend will refresh the useSession hook and its data. Without this call, the session will be updated but won't directly trigger changes if using useSession

await signIn('email', { redirect: false });

[aman-godara-ria]

@pbell23 how did you get access to req in jwt() callback? It is not in the arguments ({ token, user, isNewUser })

[aman-godara-ria]

btw as per my understanding doing getSession() will update the state of useSession hook, so instead of doing signIn() and making unnecessary redirects and whatnot, you can do getSession() to reflect the changes on client that your fetch call did.

[pbell23]

1. You need to use the advanced initialization for the [...nextauth].ts file. Check out this page https://next-auth.js.org/configuration/initialization#advanced-initialization where it is explained.
2. Just tested it using getSession, unfortunately, I get the new session when this function returns but the useSession hook is not updated, you have to refresh the page. I will continue to use the signIn function until there is a better option.

[aman-godara-ria]

Thanks!, too bad I was expecting session to update on getSession call or atleast that's what intuitively the behaviour should have been.

Actually, I am using OAuth providers and hence using signIn() is not preferable for me to update states because it causes a page reload. So was thinking of non-reload ways of updating the state. Thanks for the prompt reply!

[aman-godara-ria]

Just happened to stumble upon this solution to update session: https://next-auth.js.org/getting-started/client#updating-the-session
This seems to solve exactly what we are trying to solve here. @MaxRandle

[MaxRandle]

Amazing. Thanks @balazsorban44

[HamedBahram]

How would you update the session if you have mutated the user server-side e.g. in getServerSideProps() ?

[rolanday]

+100, this is fantastic! Solve a lot of workaround hackery!! Thank you, @balazsorban44 !!!!!!!!!

[y-nk]

@HamedBahram i was looking for the same thing as you. still waiting for a proper answer, but in the meantime this looks like doing the trick https://dev.to/nick/nextauth-jwt-how-to-update-the-session-after-login-2e68

[DibPuelma]

Thank you so much!

[basememara]

The update trigger is a great addition, thx to the NextAuth team!

Just wondering though, why wouldn't the adapter be automatically called when the update is triggered? Currently, I have to manually call the adapter but feels like this should be in the source code:

const adapter = AuthRestAdapter();

export const authOptions: AuthOptions = {
  adapter,
  providers: [...],
  ...
  callbacks: {
    async jwt({ token, user, trigger }) {
      const newToken = token;

      if (trigger === 'update' && token.sub) {
        const latestUser = await adapter.getUser(token.sub);

        if (latestUser) {
          user = latestUser;
        }
      }

      if (user) {
        newToken.property1 = user.property1;
        newToken.property2 = user.property2;
      }

      return newToken;
    }
  },
  ...
}

[valentinradu]

This looks like an oversight? Kinda makes sense to have the latest user on update.

[davidtranjs]

Where did you pass the trigger value ? I don't find it in jwt function params

[boredland]

Is there a way to do the same via getSession, so we could trigger this outside of a hook? trying to call

await getSession({
      triggerEvent: true,
      broadcast: true,
});

does not set a trigger for me in the jwt callback.

[douglasrcjames]

I got this manually updating session token to work, but is there a way to manually update the token of another user, rather than the current user? The use case is I want a Super admin to be able to update another user's admin role down to a normal user role (removing permissions), but I want to have that select user by ID to have their permissions revoked asap, instead of waiting for that user to manually update their session.

[basememara]

I'm faced this need as well. A few ways I'm thinking about how to tackle this:

1. Connect every user to a web socket and push a message to the effected user to update their token. But this is a huge infrastructure overkill.
2. Have very short lived JWT tokens like 5 minutes. But the token refresh has to to be solid and there's nothing build in for that; plus 5 minutes may be too long in a security breach moment
3. Manually update the token on every router change. But probably a big performance hit because now calling the database each time for each user many times; defeats a big benefit of JWT.

I'm thinking of going with 3 because it seems the easiest and less work, and a decent solution. I would love something built-into NextAuth for this use case, but maybe tricky because the user client side needs to do this I think, unless something in [next-auth].ts can update a user's cookie during a request?

[basememara]

Btw I do want to mention something else that I've already done that may help in the meantime. I created a session refresh component that update's the token on first load and placed it in the root <App />. This way, at least when the user closes the tab or window and comes back, the token is updated with the latest:

export default const SessionRefresh = () => {
  const { status, update } = useSession();
  const [isInitialized, setIsInitialized] = useState(false);

  useEffect(() => {
    if (status === 'authenticated' && !isInitialized) {
      update(); // Refresh session from database on first load
      setIsInitialized(true);
    }
  }, [status, isInitialized, setIsInitialized, update]);

  return null;
};

...

export default const App = ({ Component,  pageProps: { session, ...pageProps } }) => (
  <SessionProvider session={session}>
    <Component {...pageProps} />
    <SessionRefresh />
  </SessionProvider>
);

I'm trying to close the gap from here with the 3 options in my previous reply so the token is updated during a user's session not just in the beginning of it.

[clevermiraz]

If You Write This On useEffect() Hook then You will get an Infinite loop Problem. so be careful.

[phaobinh868]

This is how I manual set Token in server component.

import * as JWTEncode from "next-auth/jwt";
import { JWT } from "next-auth/jwt";
import { cookies } from 'next/headers';

export async function setToken(token: JWT) {
    const secureCookie = process.env.NEXTAUTH_URL?.startsWith("https://") ??
      !!process.env.VERCEL;
    const cookieName = secureCookie
      ? "__Secure-next-auth.session-token"
      : "next-auth.session-token"
    const newToken = await JWTEncode.encode({ token, secret: process.env.NEXTAUTH_SECRET??"secret" });
    const cookieStore = cookies()
    cookieStore.set(cookieName, newToken);
}

[dongineer1217]

As you know, the same thing happens when I run it in nextjs. Why is that so?

-> error log
TypeError: "salt"" must be an instance of Uint8Array or a string
at normalizeUint8Array (webpack-internal:///(rsc)/./node_modules/@panva/hkdf/dist/node/esm/index.js:21:47)
at hkdf (webpack-internal:///(rsc)/./node_modules/@panva/hkdf/dist/node/esm/index.js:47:117)
at getDerivedEncryptionKey (webpack-internal:///(rsc)/./node_modules/next-auth/node_modules/@auth/core/jwt.js:144:67)
at Module.encode (webpack-internal:///(rsc)/./node_modules/next-auth/node_modules/@auth/core/jwt.js:62:36)
at setToken (webpack-internal:///(rsc)/./src/auth.ts:29:71)
at Object.jwt (webpack-internal:///(rsc)/./src/auth.ts:150:17)

[aakash14goplani]

For NextAuth, solution is like:

const { data: session, status, update } = useSession()

Any equivalent solution for SvelteKitAuth?

[aakash14goplani]

Found the solution - https://blog.aakashgoplani.in/how-to-exchange-data-between-client-and-server-using-sveltekitauth

[TomTruyen]

For people still interested in this topic. NextAuth now has documentation on refershing the token for Google with both JWT and database strategy: https://authjs.dev/guides/refresh-token-rotation. This seems to be new since NextAuth5?

It is well written and works. I didn't test with Prisma like they do as I use MongoDB but I guess it should still work