Update Session on Server Side

[ChrisLegaxy]

Description 📓

Hello everyone. With the Next 13 with RSC by default, we tend to think more about the server-side approach.

For now, I'm not sure quite sure how to update the session on the server side.

Currently, I'm using CredentialProvider which gives me accessToken & refreshToken which I stored in my session.

The refreshToken is short-lived, only 30 mins, meaning if the user is idle for 30 mins, it won't work anymore, it will push user back to the login page and delete the session. (Just detailing)

Right now let's say I'm trying to return all the user's project/info on an RSC component. Meaning I'd have to call an API on the server side correct? Meaning everything only happens on the server side.

I'm using axios interceptor for this part, but now I'm only able to read the session (getServerSession), I can't find a way to update the session with the new accessToken/refreshToken. Since we only have useSession hook that provides the update method, I'm not sure how we can have that functionality on the server side as well.

The functionality I aim for:

1. axios call in server side with the accessToken
2. If the accessToken expire, it has the interceptor fall back to refreshToken
3. Then it updates the next auth session with the new accessToken/refreshToken, then retries the request

If anyone can assist on this, any suggestion is welcome, I'm not 100% sure if my use case is common or correct, but indeed kindly advise since I'm just starting Next 13 and indeed it quite confusing. I've gone through quite a lot of searches but couldn't find this part.

How to reproduce ☕️

N/A

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[angelhodar]

I think there isnt a way to update the session server side yet. I think #6642 is related

[Praiz001]

I have similar issue as the above! Can't update session in a server component as 'use session' which has the 'update' method only works on client side. Any idea to go around this would be appreciated.

[rinvii]

As far as I know, there is absolutely no way to update the session in a server component with Next.js app router because of the way React does streaming rendering of server components. Since you're wanting to update the session on the server, ideally you would need to set the cookies or headers. However, you just can't set cookie or headers during rendering of server components which is why the Next.js docs only say you can read them.

From what I've gathered, you can only check if the session is valid in a server component, but not update it. However, if you're wanting to update the cookies (in order to update the session), you would either have to do this on the client or in a middleware.

But since you want a more server-side approach, you can do this with middleware.

Right now let's say I'm trying to return all the user's project/info on an RSC component. Meaning I'd have to call an API on the server side correct? Meaning everything only happens on the server side.

I'm using axios interceptor for this part, but now I'm only able to read the session (getServerSession), I can't find a way to update the session with the new accessToken/refreshToken. Since we only have useSession hook that provides the update method, I'm not sure how we can have that functionality on the server side as well.

In the middleware, you can intercept those request tokens, validate those tokens (by a server-side function or API call), and finally set the response tokens and thereby updating the session.

[angelhodar]

@rinvii Thank you for the detailed response. I was thinking about implementing NextAuth with my custom backend but I dont know how to properly handle token refresh in sync with the NextAuth session expiration. I could just make my backend return tokens with 1 year expiration time but as the default session expiration for NextAuth is 1 month I think, I would like the accessToken from my backend stored inside the next-auth session to refresh when the next auth session is updated. As you say I should do it in the middleware, but I dont know how to properly do that. Do you have some sample code to check and study?

[mistercorea]

Hmmm, can it be a little smarter? so that if the client updates the access token by update method then the client can call the backend API to update the backend access token.

is that possible?

[rinvii]

@angelhodar @mistercorea

You can probably do something like this:

export const config = {
  matcher: "/:path*",
};

export const middleware: NextMiddleware = async (request: NextRequest) => {
  if (request.nextUrl.pathname.startsWith("/protected")) {
    const cookiesList = request.cookies.getAll();
    const sessionCookie = env.NEXTAUTH_URL?.startsWith("https://")
      ? "__Secure-next-auth.session-token"
      : "next-auth.session-token";

    // no session token present, remove all next-auth cookies and redirect to sign-in
    if (!cookiesList.some((cookie) => cookie.name.includes(sessionCookie))) {
      const response = NextResponse.redirect(new URL("/sign-in", request.url));

      request.cookies.getAll().forEach((cookie) => {
        if (cookie.name.includes("next-auth"))
          response.cookies.delete(cookie.name);
      });

      return response;
    }

    // session token present, check if it's valid
    const session = await fetch(`${ env.NEXTAUTH_URL }/api/auth/session`, {
      headers: {
        "content-type": "application/json",
        cookie: request.cookies.toString(),
      },
    } satisfies RequestInit);
    const json = await session.json();
    const data = Object.keys(json).length > 0 ? json : null;

    // session token is invalid, remove all next-auth cookies and redirect to sign-in
    if (!session.ok || !data?.user) {
      const response = NextResponse.redirect(new URL("/sign-in", request.url));

      request.cookies.getAll().forEach((cookie) => {
        if (cookie.name.includes("next-auth"))
          response.cookies.delete(cookie.name);
      });

      return response;
    }
    
    // session token is valid so we can continue
    const newAccessToken = await fetch("path/to/custom/backend") // or a server-side function call
    const response = NextResponse.next()
    const newSessionToken = await encode({
      secret: env.NEXTAUTH_SECRET,
      token: {
        ...otherTokenData,
        accessToken: newAccessToken,
      },
      maxAge: 30 * 24 * 60 * 60, // 30 days, or get the previous token's exp
    })

    // update session token with new access token
    response.cookies.set(sessionCookie, newSessionToken)

    return response;
  }

  return NextResponse.next()
}

[rahulkrishnakumar]

fetch inside middleware ? looks costly.

[codersaadi]

i think auth js too uses the fetch inside auth , when you use auth middleware in authjs .
the reason is simple that nextjs edge runtime does not support db adapters (they mostly requires node environment) so it uses a fetch call to the rest endpoint , which can use database adapter , because the endpoint will be in node env.

[Gustavo-Pauli]

i love you so much, i was nearly crying, i just lost so many hours.... i will never use auth.js again after this project, all the similar issues being closed with no clear fixes is ridiculous.

[codersaadi]

i love you so much, i was nearly crying, i just lost so many hours.... i will never use auth.js again after this project, all the similar issues being closed with no clear fixes is ridiculous.

what you could fork or use my solution it is much better plus i guess there is no competitor to next auth in the opensource market right now .
there is better auth , but it is not better .

next auth is not bad only their docs are .
like for the docs of next auth ,
you will have to read like
first authjs, then next auth v4 , then nextjs docs authentication session , then orm whatever you use .
today i was providing a lecture on that on google meet , he hired me only for that so i could teach him , he was a wonderful client.
i would recommend you to understand and use authjs .

https://github.com/codersaadi/turborepo-shadcn.

i could teach whoever wants to learn .
userid925925@gmail.com

[codersaadi]

fetch inside middleware ? looks costly.

yeah but it depends on the use case, i have shifted auth to oidc providers like zitadel. authjs looking unstable we are waiting for v5.
i guess they are doing work on the pass keys and webauth .. so therefore it is in beta , anyway, the only hack in authjs to create a shared config that supports the edge runtime (without db adapters etc) and use it in the middleware and create a new instance of NextAuth using that config.
i have grasped the concept
but still it is not a great architecture to me , the authjs abstraction is bad .

[angelhodar]

@rinvii Thank you so much for the code! I currently dont have much time for testing but I will do it for sure this weekend, the only missing piece is the encode function that I dont know where is exported from next-auth. I think this should be added to the next auth documentation, I have seen some issues that could be solved with this. Maybe its planned to be added in v5? Any maintainer can confirm?

[arminhupka]

@rinvii Thank you so much for the code! I currently dont have much time for testing but I will do it for sure this weekend, the only missing piece is the encode function that I dont know where is exported from next-auth. I think this should be added to the next auth documentation, I have seen some issues that could be solved with this. Maybe its planned to be added in v5? Any maintainer can confirm?

import {encode} from 'next-auth/jwt'

[arminhupka]

@rinvii the one issue with your solution is that we getting old token in getServerSession after refresh. We need reload page to get new token.

[angelhodar]

@rinvii I have reworked and tested your idea and it works!!! I just moved the signOut functionality to a function to make it more clear (as next-auth doesnt provdce a way to sign out server side I think). The only problem, as @arminhupka mentioned, is that the previous session gets stale, so the page needs to get reloaded. I dont know if there is a way to force next-auth to get the new session or if the middleware can force a page reload.
)

import { NextMiddleware, NextRequest, NextResponse } from "next/server";
import { encode, getToken } from 'next-auth/jwt'

export const config = {
  matcher: "/protected",
};

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

function signOut(request: NextRequest) {
  const response = NextResponse.redirect(new URL("/api/auth/signin", request.url));

  request.cookies.getAll().forEach((cookie) => {
    if (cookie.name.includes("next-auth"))
      response.cookies.delete(cookie.name);
  });

  return response;
}

function shouldUpdateToken(token: string) {
  // Check the token expiration date or whatever logic you need
  return true
}

export const middleware: NextMiddleware = async (request: NextRequest) => {
  console.log("Executed middleware")

  const session = await getToken({ req: request })

  if (!session) return signOut(request)

  const response = NextResponse.next()

  if (shouldUpdateToken(session.accessToken)) {
    // Here yoy retrieve the new access token from your custom backend
    const newAccessToken = "Session updated server side!!"

    const newSessionToken = await encode({
      secret: process.env.NEXTAUTH_SECRET,
      token: {
        ...session,
        accessToken: newAccessToken,
      },
      maxAge: 30 * 24 * 60 * 60, // 30 days, or get the previous token's exp
    })

    // Update session token with new access token
    response.cookies.set(sessionCookie, newSessionToken)
  }

  return response
}

[invisibleved]

Have you ever encountered this error "SyntaxError: Unexpected token 'S', "Service Unavailable" is not valid JSON"

[alireza-asgharii]

It's really working! Thank you.

[alireza-asgharii]

Let me just explain one thing, some friends may encounter this:

In version 5 or higher, there is a change in token encoding that you should pay attention to, otherwise it will not work

From this version, the salt value is necessary and we must set this value to the same as the cookie name:

export const SESSION_SECURE = process.env.AUTH_URL?.startsWith("https://");
export const SESSION_COOKIE = SESSION_SECURE
  ? "__Secure-authjs.session-token"
  : "authjs.session-token";


 const newSessionToken = await encode({
        secret: process.env.AUTH_SECRET,
        token: newToken,
        maxAge: SESSION_TIMEOUT,
        salt: SESSION_COOKIE,
      });

Full explanation

[lc-thanh]

@NanningR @alireza-asgharii It worked in version 5.0.0-beta.25. Thank you very much!

[alireza-asgharii]

@NanningR @alireza-asgharii It worked in version 5.0.0-beta.25. Thank you very much!

I'm glad it solved your problem.

[rinvii]

@arminhupka @angelhodar Everything is aggressively cached in Next.js https://nextjs.org/docs/app/building-your-application/caching. So I’m going to need more context about the session staleness. Otherwise it just sounds like a caching problem where soft navigations don’t trigger middleware in the way that you want (I think).

[angelhodar]

@arminhupka @angelhodar Everything is aggressively cached in Next.js https://nextjs.org/docs/app/building-your-application/caching. So I’m going to need more context about the session staleness. Otherwise it just sounds like a caching problem where soft navigations don’t trigger middleware in the way that you want (I think).

I have tested with the example next-auth template which is based on the pages router. I think the new caching mechanism that seems to be more aggresive and sometimes gives problems is only in the new app router, am I right? The main session staleness problem I think that comes mainly from the SessionProvider, because I suppose it stores the session in memory to just return it in the useSession hook instead of making a network request everytime the hook is called (I dont know internally how it works but makes sense)

One possible solution would be to return an extra cookie that tells the client if it has to call the new update method from the useSession hook to force a session reload. That could be implemented in a background component that just executes its useEffect on every route change. I am sure that there is a more elegant solution to force next-auth to refresh the session but I dont know how to do it.

Edit: I have just read in the docs that the update method doesnt sync across tabs, so the getSession function should be called as its specified:

If you have session expiry times of 30 days (the default) or more then you probably don't need to change any of the default options in the Provider. If you need to, you can trigger an update of the session object across all tabs/windows by calling getSession() from a client side function

[rinvii]

I avoid using the auth HOC and client side functions like useSession. I don’t understand what is meant when the previous session gets stale. An example play by play would be appreciated. And, I store the session in cookies and avoid storing it in client memory.

[fivaz]

@rinvii Thank you so much, your middleware idea actually worked !

I just had to do a small adjustment, because if the encoded token is longer than 3933 characters, Next Auth will split it into multiple tokens with the names cookie-name.[0], cookie-name.[1], cookie-name.[2], etc.

so I just had to do a small adjustment to your code

import { NextMiddleware, NextRequest, NextResponse } from 'next/server';
import { encode, getToken, JWT } from 'next-auth/jwt';


async function refreshAccessToken(token: JWT): Promise<JWT> {
  // implement how you're gonna fetch a new token with the old one
}

export const config = {
  matcher: [..your protected routes],
};

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

function signOut(request: NextRequest) {
  const response = NextResponse.redirect(new URL('/api/auth/signin', request.url));

  request.cookies.getAll().forEach((cookie) => {
    if (cookie.name.includes('next-auth.session-token')) response.cookies.delete(cookie.name);
  });

  return response;
}

function shouldUpdateToken(token: JWT): boolean {
  // check if you're token is expired
}

export const middleware: NextMiddleware = async (request: NextRequest) => {

  const token = await getToken({ req: request });

  if (!token) return signOut(request);

  const response = NextResponse.next();

  if (shouldUpdateToken(token)) {
    const newToken = await refreshAccessToken(token);

    const newSessionToken = await encode({
      secret: process.env.NEXTAUTH_SECRET as string,
      token: {
        ...token,
        ...newToken,
      },
      maxAge: 30 * 24 * 60 * 60,
    });

    const size = 3933; // maximum size of each chunk
    const regex = new RegExp('.{1,' + size + '}', 'g');

    // split the string into an array of strings
    const tokenChunks = newSessionToken.match(regex);

    if (tokenChunks) {
      tokenChunks.forEach((tokenChunk, index) => {
        response.cookies.set(`${sessionCookie}.${index}`, tokenChunk);
      });
    }
  }

  return response;
};

[mabutalid]

@rinvii the one issue with your solution is that we getting old token in getServerSession after refresh. We need reload page to get new token.

Hi I have reference this thread in order to refresh the token in middleware when the access token expires and the solution and sample code given by @rinvii was great and I thank you for that Godbless you. As for the issue regarding the old token still being returned by the getServerSession after refresh its because in the middleware it also needs to set the new session cookies at the request object not just the response since the getServerSession would read at the request cookies not the response cookies so basically you need to the set the new session on both the request and response cookies.

• request cookies for the getServerSession to read
• response cookies to send back to the browser

it would look like this:

// set request cookies for the incoming getServerSession to read new session
      tokenChunks.forEach((tokenChunk, index) => {
        req.cookies.set(`${sessionCookie}.${index}`, tokenChunk);
      });

      // updated request cookies can only be passed to server if its passdown here after setting its updates
      const response = NextResponse.next({
        request: {
          headers: req.headers,
        },
      });

      // set response cookies to send back to browser
      tokenChunks.forEach((tokenChunk, index) => {
        response.cookies.set(`${sessionCookie}.${index}`, tokenChunk, {
          httpOnly: true,
          maxAge: 1 * 24 * 60 * 60, // 1 day
          secure: !!isCookieSecure,
          sameSite: "lax",
        });
      });

      console.log("TOKEN REFRESH SUCCESSFUL...");

      return response; 

[kokombo]

Please I was able to update user session by calling update in onClick handler but causing problems when called in a useEffect.

Also, the documentation says you can call update() without the page reloading. That doesn't seem to the case.

[coreyward]

useSession().update() should not cause a reload, but it will trigger any components that consume the session via useSession() to re-render due to the SessionProvider context being updated.

[Yassin-Samir]

`import { getServerSession } from "next-auth";
import { NextAuthOptions } from "./api/auth/[...nextauth]/route";
async function Server() {
const session = await getServerSession(NextAuthOptions);
console.log({ server: session });
}

export default Server;`
place authoptions in getserversession

[NanningR]

I’ve tried to debug my problem with the overridden token in the production environment and came to the point that SessionProvider is calling getSession just after the page is reloaded and a new token is generated but it is using old token instead of a newly generated and probably set the old one in the cookie (override newly generated). TBH I am not sure why it is happening in the production environment.

Maybe it has to do with one of the following:

• When you set the response cookie, you don't set the "secure" attribute. It should be something like: secure: process.env.NODE_ENV === "production",
• You need to take into account the fact that tokens will be split up into chunks if they become too large

For me, it's working fine in production. I've combined a few of the answers above and deployed to Azure Portal.

[NanningR]

@dmarkowski actually, re-reading your comment, you should probably stay away from client side functions like getSession() and useSession(). In fact, when using the app router, you don't need a SessionProvider at all. You just export something like

export async function getAuthSession(): Promise<Session | null> { return await getServerSession(authOptions); }

From wherever you have authOptions available. Then you can call

const session: Session | null = await getAuthSession();

In any server component and pass the session as props to client components. I can guarantee you that this works; I've had it implemented for a few weeks now, and I haven't had any problems. I would recommend to leave out the added complexity of working with large and chunked tokens whenever possible. Instead of saving the ID token in my session cookie, I just have the basics like the access- and refresh token. Just pick an OAuth provider that supports OIDC (most do) and call the /o/userinfo endpoint with the access token.

@BowaDAO This might also be useful for you. If you do need to call session hooks from client components though, you should use getSession() to update the session object across all tabs/windows just as @angelhodar pointed out.

@hobadams Have you tried implementing the encode logic yourself? It should be really easy, since Auth.js v5 uses general JWT methods available in npm packages to encode and decode its tokens. See: https://github.com/nextauthjs/next-auth/blob/main/packages/core/src/jwt.ts for more info. After this, you can just set the cookies in the middleware

[DespotB]

As far as I understand the docs getSession() is not a client side function: https://nextjs.org/docs/app/building-your-application/authentication#session-management

[NanningR]

@DespotB I understand the confusion, we are specifically talking about nextauth's functions. It provides various client side functions, like useSession() and getSession(): https://next-auth.js.org/getting-started/client. It also links to the server alternative getServerSession().

@roboalbers Weird! I can't determine what's causing the chunked token problem based on your code. You should probably still check the contents of my token by just console.log()'ing it out. Something must be making it reach the threshold. Anyway, I'm glad it's working for you with the way you set the chunked tokens! I think my problem was that I used RegExp.exec() instead of match(), which didn't work, after which I wasted time trying to implement nextauth's native functions myself. I've now implemented it with match() too, just to be sure, but I still keep my tokens as small as possible. Hopefully Next.js / Auth.js come up with a real solution soon so we can ditch these workarounds.

[maxbec]

hey @NanningR,

maybe you have an idea how to solve the following problem.
We implemented your token logic into the middleware and it is working fine. But with a lot of users and on high refresh rates the logic is failling.

The problem is with asychronous, parallel middlewares running. We lock a token during it is refreshed. But on a lot of requests at the same time it can happen, that during refreshment another request is send with the currently refreshing token. It now also tries to refresh it's token but the api call is failing because the refresh token was already refreshed in the first thread and so it is invalid now. The user gets logged out.

So how can we solve this problem of parallel middleware threads trying to refresh a token in the cookie?

[NanningR]

@maxbec I don't really understand your situation; even though a lot of refreshes can happen at the same time, it should only happen once for each user, right? And what do you mean with parallel middlewares running? Are you running next.js in cluster mode?

Example (ecosystem.config.js):

module.exports = {
	apps: [
		{
			name: "XXX",
			script: "./node_modules/next/dist/bin/next",
			args: "start -p " + (process.env.PORT || 3000),
			watch: false,
			instances: "max",
			exec_mode: "cluster",
			autorestart: true
		}
	]
};

In that case, all users should probably routed / locked to once vCPU thread / instance. Google / ChatGPT on how to do this; I have yet to implement this myself. But this should only matter for concurrency sensitive things like data mutations, etc. Due to the nature of JWT sessions, this should not really be a problem. In fact, the refreshed session should even be available across multiple tabs.

I will soon experiment with next.js cluster mode, and if you provide some more information, I might try to reproduce your problem :) Take care

[maxbec]

No we are not running in cluster mode. But we manually hitted the refresh button with mouse clicks quite often (spamming). And after a while we got logged out because he tried to refresh the token from the cookie but this refreshToken was already refreshed and invalid. But the refresh happened that fast that the new cookie with the new token wasnt there yet.

[Namaskar-1F64F]

For anyone who is using Vercel for hosting, it is likely the NEXTAUTH_URL in some of the code snippets is un-set since the URL is derived from the system environment variables automatically.

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

That means, the sessionCookie will never start with https and potentially make you waste two days very confused. Instead, I'm using:

  const sessionCookie =
    process.env.VERCEL_ENV === 'development'
      ? 'next-auth.session-token'
      : '__Secure-next-auth.session-token'

Also, I wrote a blog post that might be helpful. It's about using a dual-auth GitHub provider setup and flow, which includes the middleware here. Thanks everyone for the discussion.

[NanningR]

@maxbec Have you tried playing with options Next.js's fetch implementation provides? If not, you should check out: https://nextjs.org/docs/app/api-reference/functions/fetch. In short, you should be able to do something like this (add to the fetch method in middleware.ts:

method: "POST",
next: {
    revalidate: 1
}

Furthermore, an update on this issue:

I've noticed that using server-side functions redirect() and permanentRedirect() right after refreshing the tokens breaks the logic, making it such that subsequent refreshes are attempted with the old, now invalidated refresh token. If you want to redirect from within a server component, you should handle this through a client side function with router.push(). For example:

import "server-only";

import React from "react";
import { type Session } from "next-auth";

import { getAuthSession } from "@/lib/auth/AuthOptions";
import AuthRedirect from "@/components/general/AuthRedirect";

export default async function App(): Promise<JSX.Element> {
	const session: Session | null = await getAuthSession();

	return <AuthRedirect session={session} />;
}

And then:

"use client";

import React, { useEffect } from "react";
import { useRouter } from "next/navigation";
import { type Session } from "next-auth";
import { signIn } from "next-auth/react";

export default function AuthRedirect({
	session,
	url = "/dashboard"
}: Readonly<{ session: Session | null; url?: string }>): JSX.Element {
	const router = useRouter();

	useEffect(() => {
		if (!session?.user) {
			signIn("provider name")
				.then(() => router.push(url))
				.catch((err) => console.error(err));
		} else {
			try {
				router.push(url);
			} catch (err) {
				console.error(err);
			}
		}
	}, [session, url, router]);

	return <div className="flex h-screen items-center justify-center"></div>;
}

[ARJohnsonKwik]

You can memoize the refresh token function. So, if something calls it with the old refresh token, it will now return the previous value and won't re-run the refresh logic.

[NanningR]

@ARJohnsonKwik Was your response in regard to my suggestion to maxbec or the redirect problem? In both cases, how would you memoize the value server side? Because using the cache / revalidate options built into Next, like explained here: https://nextjs.org/docs/app/api-reference/functions/fetch, you are essentially already doing that same exact thing. I tried playing with it to solve the redirect problem, but unfortunately, to no avail (hence my client-side redirect solution). It does however prevent problems in other cases.

[AndrewRayCode]

I think I'm missing something.

We use the session to store information related to the session, user, server side data, etc. Being able to update the session server side data is a 101 requirement for any auth/session library. Exposing a client-only ability to update a session in an auth library would be unusual, as I think it would be insecure by default. Clients generally shouldn't be able directly update session data. This is why I think I'm missing something, updating the session client API fundamentally doesn't make sense, this option should not be exposed to clients.

The previous comments about hacks to overwrite the cookie value for the session can't be the right way to do this, because it wouldn't make sense for a library that affords sessions to have an insecure first class way to do this on the client, but not on the server. But getServerSession doesn't document how to update the server side session.

I feel like I must have some ignorant view here, someone please correct me on my misconception. next-auth is a very popular library, and server session updating is a requirement of libraries that manage sessions, and my understanding is next-auth doesn't have a way to do this, so one of my assumptions in this list is likely wrong.

[coreyward]

I think there are two things being discussed here. One is challenges with the app router limitations, as @NanningR summarizes well. The other is challenges with communication between the server and client in a SPA.

Say the client makes a POST request to /api/foo and that endpoint modifies the session data and returns a { success: true } response with an updated JWT in a cookie. The front-end app does not know that the cookie changed—it's not only encrypted (client can't access the original value), but it's HTTP-Only, so the client can't even see that the cookie exists. As a result, there isn't any automatic way for the front-end code to know that the session has been updated—it has to request a new value from the server, which is what it does when you call getSession(). This will also happen as part of calling useSession().update(). Provided you have <SessionProvider> mounted, there are other scenarios that will trigger a refresh of the session automatically, too, such as the user leaving the tab and coming back, the session being updated in another tab.

Now if you update the session server-side and redirect the client then redirects to another page (as in, a full page load, not a client-side navigation) everything works as you might expect: the new page reads the updated cookie, sends the updated value along with the page props, and both the server and client render have access to the new value.

[musjj]

From my attempts, I can only manage to update the session using server actions (with unstable_update) if I add an update logic to my JWT callback (by reading jwt({ session })).

But this defeats the purpose of server-side updates, because we're now exposing the ability to edit sessions to the client anyways. AFAIK, the client can feed any data to the session.

Can anyone clarify me on this, because I'm still very lost.

[AndrewRayCode]

@NanningR I'm not sure what you're referring to. This is absolutely a next-auth problem, and this is not related to the app router nor callbacks.

@coreyward SPAs are bad for performance, SSR is the main and most common use case here for updating the JWT from the server.

If a JWT contains the users email or roles, and those change, you need to update the JWT. This is 101 cookie stuff. That's all it is. Obviously any server-side API route should be able to do this as a first class API from next-auth. Not exposing a way to read and modify and re-set the cookie as a first class API is baffling.

Trying to hack apart the cookie in middleware does not make sense, the use case of updating the JWT is not something you want to do blindly before every route loads in a middleware call. Get, update, set cookie, that's all that's needed.

Now "Auth.js" released an undocumented, "unstable_update()" that can maybe do this? I think I'm missing something. A first class API to update the session cookie is basic functionality required by any auth library.

[coreyward]

@AndrewRayCode Either you're in a combative mood or you don't understand what I wrote, or both. You probably should go back and re-read my comment above because while I understand where you're coming from with the desire for a server-side API to update the cookie, what you're recommending will create lots of bugs in a Next.js app due to client-side routing (SPA).

[AndrewRayCode]

For anyone looking for a different solution - for a standard SSR setup - I store only the user ID in the session, and on each SSR page load, I re-fetch the relevant data for the user as server side props, and pass those to the client. This means when there are things that need to update the user's state, like an email change, they are refetched from the database on each page load. SSR and server-side data fetching is good for performance, so this works fine.

Next.js lets you update cookies wherever you want to, including server actions. All next-auth has to do is expose an API to do this, and users can choose which server-side calls can update the session cookie. There is no need to couple it to the problems inherent to client side navigation or other SPA issues. There just needs to be a first class way to update the session (aka cookie), which is 101 web server stuff, and users can call it where they need to. It is at best a missing feature, and at worst a design flaw, in next-auth, that there is no way for users to do this out of the box.

[hobadams]

I've implemented the middleware suggestion with Okta as a provider as discussed in the some of the comments above (thanks everyone for the help).

I now have 1 outstanding issue.

I use the access token as a header for some of my API requests. These use a Next API route as a proxy so I can access my token. The issue is, as far as I'm aware the refresh token logic that happens in the middleware happens during client side routing and not API requests (triggered by the client).

Has anyone implemented a solution for this? My guess is i need to check the expiry of the access token in the API proxy too and intercept all requests at that point....but then I'm back to the original issue of how to update the clients cookie for there.

Any help would be appreciated.

Some context

In case I didn't explain it well. If you navigate around the app the middleware does it's thing and refreshes the token and browser cookie as and when it expires. If I sit on a single page and don't navigate away (using Next router) until the access token expires (5 mins in my case). I then trigger an API request from the application using a button. This request fails because the access token has expired.

[shobhit99]

Facing same issue, got the middleware part sorted, but if i am sitting idle on page and calling any api from browser and if at that point my jwt access token has expired i get 401 again, I am able to update client cookie with new session but when middleware calls getSession() again, it retrieves old session again

[shobhit99]

I seem to have solved this issue, key is to call the nextjs route api so that it goes through middleware as middleware updates both server and client side

What i did is on my xhr request i checked if api responded with 401 and if yes i called the auth/refresh-session endpoint which is Nextjs api route, it's just dummy api which i made so that i can intercept it in middleware

I added /auth/refresh-session in matcher, so i am getting it in middleware
and i check if the url ends with refresh-session combined with @rinvii and @angelhodar code, I call the refresh token api, create the new session cookie, set the cookie along with the new tokens as json response

This is how my middleware file looks like

import { NextMiddleware, NextRequest, NextResponse } from 'next/server';
import { encode, getToken, JWT } from 'next-auth/jwt';
import * as jwt from 'jsonwebtoken';


async function refreshAccessToken(token: JWT): Promise<JWT> {
  const response = await fetch(`${process.env.CORE_API_URL}/auth/refresh`, {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: JSON.stringify({ refresh_token: token.refreshToken })
  });
  if (!response.ok) {
      const failedResponse = await response.json();
      throw new Error('Failed to refresh token');
  }
  const data = await response.json();
  return data;
}

export const config = {
  matcher: ['/dashboard', '/services', '/forms', '/auth/refresh-session'],
};

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

function signOut(request: NextRequest) {
  const response = NextResponse.redirect(new URL('/login', request.url));

  request.cookies.getAll().forEach((cookie) => {
    if (cookie.name.includes('next-auth.session-token')) response.cookies.delete(cookie.name);
  });

  return response;
}

const  shouldUpdateToken =  (token: JWT) => {
  const currentTimeInSeconds = Math.floor(Date.now() / 1000);
  const decoded = jwt.decode(token.accessToken);
  return decoded.exp < currentTimeInSeconds;
}

export const middleware: NextMiddleware = async (request: NextRequest) => {

  const token = await getToken({ req: request });

  if (!token) return signOut(request);

  const response = NextResponse.next();
  const updateToken = shouldUpdateToken(token);
  if (updateToken) {
    const newToken = await refreshAccessToken(token);

    const newSessionToken = await encode({
      secret: process.env.NEXTAUTH_SECRET as string,
      token: {
        ...newToken
      },
      maxAge: 30 * 24 * 60 * 60,
    });

    response.cookies.set(sessionCookie, newSessionToken)

    if (request.url.endsWith('refresh-session')) {
      return Response.json({
        ...newToken
      }, {
        status: 200,
        headers: {
          'Set-Cookie': `${encodeURIComponent(sessionCookie)}=${newSessionToken}; Path=/`
        }
      })
    }

  }

  return response;
};

This is my useAxiosAuth.ts file

'use client';

import { useSession } from "next-auth/react"
import { useEffect } from "react";
import { axiosAuth } from "../axios";
import { useRefreshToken } from "./useRefreshToken";

const useAxiosAuth = () => {
    const { data: session } = useSession();
    const refreshToken = useRefreshToken();

    useEffect(() => {
        const requestIntercept = axiosAuth.interceptors.request.use(async (config) => {
            let accessToken = session?.user.accessToken;
            
            if (!config.headers['Authorization']) {
                config.headers['Authorization'] = `bearer ${accessToken}`
            }
            return config;
        },
        (error) => Promise.reject(error)
        );

        const responseIntercept = axiosAuth.interceptors.response.use((response) => response, async (error) => {
            const prevRequest = error.config;
            if (error.response.status == 401 && !prevRequest.sent) {
                prevRequest.sent = true;
                await refreshToken();
                prevRequest.headers["Authorization"] = `bearer ${session?.user.accessToken}`;
                return axiosAuth(prevRequest);
            }
            return Promise.reject(error);
        })

        return () => {
            axiosAuth.interceptors.request.eject(requestIntercept);
            axiosAuth.interceptors.response.eject(responseIntercept);
        }
    }, [session])

    return axiosAuth;
}

export default useAxiosAuth;

This is my useRefreshToken.ts file

"use client"

import { useSession } from "next-auth/react";
import axios from "axios";

export const useRefreshToken = () => {
    const { data: session } = useSession();

    const refreshToken = async () => {

        if (session) {
            try {
                const resp = await axios.post("/auth/refresh-session", {
                    refreshToken: session?.user.refreshToken
                });
                if (session) {
                    session.user.accessToken = resp.data.accessToken;
                    session.user.refreshToken = resp.data.refreshToken;
                }
                return resp.data;
            } catch (err) {
                console.log("err", err)
            }
        }
    }
    return refreshToken;
}

If you need more context about useAxiosAuth and useRefreshToken, it was something i copied while following along this tutorial on youtube about refresh token in next auth https://www.youtube.com/watch?v=RPl0r-Yl6pU

Hope it helps

[yaarchee]

yes, but when useSession or something similar is used, then in browser requests we will see a session request, in response to which an access token and a refresh token will be visible, which is not good. Or I'm wrong?

[ash33rr]

I’ve been facing a similar issue with my token refresh mechanism. I have a middleware setup along with useAxiosAuth and useRefreshToken, but sometimes my useRefreshToken sends a request with the old token.

I noticed that you mentioned creating an API route in Next.js to trigger the middleware, which updates both server and client-side tokens. Could you please share if everything is working smoothly with your setup? Would you be able to share your code or any insights?

Thanks a lot for your help!

[emreakdas]

this way I can update with the update method given. i didn't know that...

[emreakdas]

@balazsorban44 is this something new? why is it not mentioned in the documentation.

[Kledal]

For anyone using the latest beta version (nextauth -> authjs) you need to update the sessionCookie names to:

const sessionCookie = process.env.NEXTAUTH_URL?.startsWith("https://")
    ? "__Secure-authjs.session-token"
    : "authjs.session-token";
    ```

[nlm-pro]

For anyone looking for a way to update the session object from an RSC in v4 the same way you would do on the client-side using const { update } = useSession(), here it is:

import { cookies } from 'next/headers'

export default async function MyPage() {
  const cookieStore = cookies()
  // or options.cookies.csrfToken.name if you overrides it
  // see https://next-auth.js.org/configuration/options#cookies
  const csrfToken = cookieStore.get('next-auth.csrf-token')?.value

  if (csrfToken) {
    // update the session (undocumented next-auth feature)
    // see https://github.com/nextauthjs/next-auth/blob/ebfdaece/packages/next-auth/src/react/index.tsx#L474-L479
    // and https://github.com/nextauthjs/next-auth/blob/ebfdaece/packages/next-auth/src/core/index.ts#L297-L308
    // using the client CSRF Token is required
    // see https://github.com/nextauthjs/next-auth/blob/ebfdaece/packages/next-auth/src/core/init.ts#L118-L127
    // and https://github.com/nextauthjs/next-auth/blob/ebfdaece/packages/next-auth/src/core/lib/csrf-token.ts#L41
    fetch(myAppUrlHelper('/api/auth/session'), {
      method: "POST",
      headers: {
        'Content-Type': 'application/json',
        cookie: `next-auth.csrf-token=${csrfToken}`
      },
      body: JSON.stringify({
        csrfToken: csrfToken.split('|')[0],
        data: {
          foo: 'bar'
        }
      })
    })
  }
 
 // ... 
}

And don't forget to handle it in options.callbacks.jwt the same way you would when using useSession().update:

callbacks: {
    async jwt({ user, token, account, trigger, session }): Promise<JWT> {
    
       // ...

       if (trigger === 'update') {
          return {
            ...filteredToken,
            foo: session.foo
          }
       }
    }
 }

[nlm-pro]

You're talking about an experimental feature in a beta.
I'm talking about the stable version (v4) we use in production.

[emreakdas]

Ah! Yeah, we're using v5.

[w00ye0l]

myAppUrlHelper is where?

if (csrfToken) {
  fetch("/api/auth/session", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      cookies: `authjs.csrf-token=${csrfToken}`,
    },
    body: JSON.stringify({
      csrfToken: csrfToken?.split("|")[0],
      user,
    }),
  });
}

I sent the request like this, but it doesn't seem to reach the jwt callback.

[ruben-888]

@w00ye0l "myAppUrlHelper" is not shown in the example, but it would simply be some sort of helper function that was created to return a full URL path to make that request. To call an API route server-side you need (for example) to call:

 fetch("http://localhost:3000/api/auth/session", ...

And NOT the relative path:

 fetch("/api/auth/session", ...

[ambangeles]

POST /api/auth/session 200 in 141ms
{
  user: {
    email: 'test@email.com',
    id: 'Jj4EAACTxwCLAN',
    first_name: 'name',
    last_name: 'Angeles',
    access_token: 'hihi',
    refresh_token: 'hihi',
    access_token_expiration: 1730802668,
    refresh_token_expiration: 1730806263,
    redirect_url: '/admin/3'
  },
  expires: '2024-11-05T12:39:06.520Z'
}

when i tried this fetch and call it in the server component and log response.json(), i was getting this response from the fetch. now how can i put it in the browser since when i tried to see the session it still has the old session not this logged in the console.

[nackamoto]

@emreakdas can you demonstrate how you use unstable_update. I am using v5 and want to update the session from the server.
This is what i have tried:

export const serverRefreshToken = async() => {
    const session = await auth();
    async function updateSession(res: AxiosResponse<AuthInterface.AuthResponse, any>) {

        await unstable_update({
            ...session,
            user: {
                ...session?.user,
                avatar: res?.data?.data?.user?.avatar,
                accessToken: res?.data?.data?.accessToken,
                refreshToken: res?.data?.data?.refreshToken,

            }
        })

    }
    
    ```

[emreakdas]

@NafiAsib yes I am sure we are using it now in our live project. there does not seem to be a problem.

[emreakdas]

how does it stay the same and where do you use it? it is a server function. so in my case I also use route handler, no problem.

[Ahsan-Ullah1871]

You can use this situation by writing a wrapper to fetch on the server side.

this is a simple use case, you can customize it as you wish.

async function _fetch(url, options){
    const session = await auth();

    if(options?.headers){
        options.headers.Authorization = `Bearer ${session.access_token}`;
    }

    return fetch(url, options);
}

async function refreshToken(){
    const session = await auth();
    const result = await fetch('/blablabla-refresh-token-endpoint?refresh-token='+session.refresh_token);

    if(result.ok){
        const json = await result.json();
        await unstable_update({
            access_token: json.access_token,
            refresh_token: json.refresh_token,
        })

        return true;
    }

    return false;
}

export default async function fetcher(url, options){
    const result = await _fetch(url, options);

    if(result.status === 401){
        const response = await refreshToken();
        if(response){
           return _fetch(url, options);
        }
    }

    return result;
}

thanks , this way i can solve my issue .

[musjj]

Is there a way to use the unstable_update server action, while still preventing the client from editing the session? If you add something like:

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

You're once again giving the client the ability to inject arbitrary data to the session, which kind of defeats the purpose of doing this from the server.

[wave-m]

how does it stay the same and where do you use it? it is a server function. so in my case I also use route handler, no problem.

I tried it your way, but unstable_update isn't working. I use next.js 14 app router, auth.js v5..

[aakash19here]

How about this ?

https://git.new/token-rotation

[Kuzmich100kM]

The idea is clear, but it does not work, the update is not called. It works for you?

[aakash19here]

yeah it works just fine

[yoss1209]

Is the refresh token updated only when entering the page?

[etnichols]

To add yet another comment to this utterly neglected thread:

The original question is asking how to update the session on the server side.

The code provided by @rinvii in this comment is a large part of the solution: #9715 (comment).

But as @arminhupka points out, there are issues with this solution: #9715 (comment).

I think the core issue here is multiple, competing Set-Cookie headers being sent in a single response, which can be caused by 1) middleware execution which performs a token refresh and explicitly sets the new next auth session token cookie, followed by execution of /api/auth/session Next Auth handler, which also sets the next auth session token cookie on the same response.

A single HTTP response with multiple Set-Cookie headers for the same cookie name is undefined behavior in the HTTP spec, with most browsers going with "last Set-Cookie call wins" to choose what actually gets set.

One can verify this case by observing the HTTP response in chrome dev tools for a call to /api/auth/session where the middleware executed before: it should be a 200, with two Set-Cookie headers.

How to handle this? One potential solution would be to 1) exempt running the middleware on Next Auth routes (/api/auth/*) and 2) move the refresh token logic directly into the next auth api handler, and perform the refresh token check / in place cookie update on the Next Auth handler's HTTP response.

Some code snippets for reference:

// middleware.ts

export default async function middleware(req: NextRequest) {
  const path = req.nextUrl.pathname;
  const token = await getToken({ req });

  if (!token) {
    return NextResponse.next();
  }

  // Do not perform any token refresh logic for Next auth routes:
  // they have their own logic to refresh tokens.
  if (path.startsWith('/api/auth')) {
    return NextResponse.next();
  }

  console.log(`🎸 [Middleware] Begin execution for path: ${path}. Request ID: ${requestId}`);

  if (shouldUpdateToken(token.authTokenExpires as number)) {
    try {
      const refreshedTokens = await refreshTokens(
        token.refreshToken as string,
        token.userId as string
      );

      updatedSessionToken.authToken = refreshedTokens.authToken;
      updatedSessionToken.refreshToken = refreshedTokens.refreshToken;
      updatedSessionToken.authTokenExpires = refreshedTokens.authTokenExpires;
    } catch (e) {
      console.error(
        `❌ [Middleware] Error refreshing tokens: ${e}. Request ID: ${requestId}. for path: ${req.nextUrl.pathname}`
      );
    }
  }

  const newSessionToken = await encode({
    secret: process.env.NEXTAUTH_SECRET as string,
    token: updatedSessionToken,
    maxAge: 1800, // 30 minutes in seconds
  });

  console.log(`🎸 [Middleware] Execution complete. Request ID: ${requestId}\n`);
  return responseWithUpdatedCookie(newSessionToken, req);
}

This code above should work for non-api routes, and loading just regular Next pages.

Below demonstrates an augmented Next Auth API route handler with in place session update, by updating the Next Auth produced HTTP response in place.

// api/auth/[...nextauth]/route.ts

const handler = NextAuth(authOptions);

// Cookie names.
export const NEXT_AUTH_SESSION_TOKEN_COOKIE = isProduction
  ? `__Secure-next-auth.session-token`
  : `next-auth.session-token`;

const wrappedAuthHandler = async (req: NextRequest, res: NextResponse) => {
  const token = await getToken({ req });
  const nextAuthResponse = await handler(req, res);
  return maybePerformTokenRefresh(token, response);
};

export { wrappedAuthHandler as GET, wrappedAuthHandler as POST };

async function maybePerformTokenRefresh(token: JWT | null, response: Response) {
  // Check if there is a Set-Cookie header with the NEXT_AUTH_SESSION_TOKEN_COOKIE name.
  // If there is, we need to see if the token is expired and needs an update.
  // Return value of getSetCookie() is an array of strings: ['cookie1=value1', 'cookie2=value2', ...]
  const setCookieHeaders = response.headers.getSetCookie();
  const nextAuthSessionTokenCookie = setCookieHeaders?.find((cookie) =>
    cookie.includes(NEXT_AUTH_SESSION_TOKEN_COOKIE)
  );

  if (!nextAuthSessionTokenCookie) {
    // No cookie found, nothing to update.
    return response;
  }

  const cookieValueWithOptions = nextAuthSessionTokenCookie.split('=')[1];
  const cookieValue = cookieValueWithOptions.split(';')[0];

  const decodedCookieAsToken = await decode({
    secret: process.env.NEXTAUTH_SECRET as string,
    token: cookieValue,
  });

  if (
    !decodedCookieAsToken ||
    !shouldUpdateToken(decodedCookieAsToken.authTokenExpires as number)
  ) {
    return response;
  }

  const updatedSessionToken = { ...decodedCookieAsToken };

  try {
    const refreshedTokens = await refreshTokens(
      decodedCookieAsToken.refreshToken as string,
      decodedCookieAsToken.userId as string
    );

    updatedSessionToken.authToken = refreshedTokens.authToken;
    updatedSessionToken.refreshToken = refreshedTokens.refreshToken;
    updatedSessionToken.authTokenExpires = refreshedTokens.authTokenExpires;
  } catch (e) {
    console.error(`❌❌ [Middleware] Error refreshing tokens: ${e}`);
  }

  const newSessionToken = await encode({
    secret: process.env.NEXTAUTH_SECRET as string,
    token: updatedSessionToken,
    maxAge: 1800, // 30 minutes in seconds
  });

  const clonedResponse = response.clone();
  clonedResponse.headers.delete('Set-Cookie');
  clonedResponse.headers.set(
    'Set-Cookie',
    createAuthCookieString(newSessionToken)
  );

  console.log('🍪[Next Auth API Handler] Refreshed token and set cookie');

  return clonedResponse;
}

With this solution, all cases where a Next Auth session token could be set should be covered, and there should be no competing Set-Cookie header calls.

I believe this sufficiently answers the OP's original question of "how to update session server side" in a way that respects an auth token/refresh token based system.

[H7ioo]

How would this look like in "next-auth": "5.0.0-beta.25"?
The auth setup is now different.

[omarjam97]

Hello, if anyone is using version:

"next-auth": "^5.0.0-beta.22"

The encode function is requiring a SALT:

    const token = await getToken({
      req: request,
      secret: process.env.AUTH_SECRET,
      salt: "saltHere"
    });

   const newSession = await encode({
        secret: process.env.AUTH_SECRET,
        token: {
          ...token,
          access_token: data.accessToken,
          refresh_token: data.refreshToken,
        },
        maxAge: SESSION_TIMEOUT,
        salt: "saltHere",
      });

I've been receiving the following error once I refresh the session:

frontend_1  | [auth][error] JWTSessionError: Read more at https://errors.authjs.dev#jwtsessionerror
frontend_1  | [auth][cause]: Error: no matching decryption secret
frontend_1  |     at clockTolerance (webpack-internal:///(rsc)/./node_modules/@auth/core/jwt.js:90:15)
frontend_1  |     at async flattenedDecrypt (webpack-internal:///(rsc)/./node_modules/jose/dist/node/esm/jwe/flattened/decrypt.js:106:15)
frontend_1  |     at async compactDecrypt (webpack-internal:///(rsc)/./node_modules/jose/dist/node/esm/jwe/compact/decrypt.js:22:23)
frontend_1  |     at async jwtDecrypt (webpack-internal:///(rsc)/./node_modules/jose/dist/node/esm/jwt/decrypt.js:12:23)
frontend_1  |     at async Object.decode (webpack-internal:///(rsc)/./node_modules/@auth/core/jwt.js:81:25)
frontend_1  |     at async Module.session (webpack-internal:///(rsc)/./node_modules/@auth/core/lib/actions/session.js:23:29)
frontend_1  |     at async AuthInternal (webpack-internal:///(rsc)/./node_modules/@auth/core/lib/index.js:47:24)
frontend_1  |     at async Auth (webpack-internal:///(rsc)/./node_modules/@auth/core/index.js:127:34)
frontend_1  |     at async Home (webpack-internal:///(rsc)/./src/app/page.tsx:11:21)
frontend_1  | [auth][details]: {}

As a workaround, I had to override the encode and decode JWT functions in NextAuthConfig:

import { decode as _Decode, encode as _Encode, type JWT } from "next-auth/jwt";
export const authConfig: NextAuthConfig = {
 //Configuration...
 jwt: {
    maxAge: SESSION_TIMEOUT,
    decode(params) {
      return _Decode({
        salt: "saltHere",
        secret: process.env.AUTH_SECRET,
        token: params.token,
      })
    },
    encode(params) {
      return _Encode({
        salt: "saltHere",
        secret: process.env.AUTH_SECRET,
        token: params.token
      })
    },
  }
}

Are there any other solutions for this?

[sandmule]

Set the salt to

const SESSION_SECURE = process.env.NEXTAUTH_URL?.startsWith('https://');
const SESSION_SALT = SESSION_SECURE ? '__Secure-authjs.session-token' : 'authjs.session-token';

[omarjam97]

Thanks It looks like NextAuth is using the cookie name as the salt.