Update Session on Server Side #9715
Replies: 31 comments 35 replies
-
|
I think there isnt a way to update the session server side yet. I think #6642 is related |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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()
} |
Beta Was this translation helpful? Give feedback.
-
|
Спасибо! Написал под себя, все заработало. Теперь обновляет при смене фокуса + обновляет при переходе на другую страницу или при рефреш. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@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
} |
Beta Was this translation helpful? Give feedback.
-
|
what logic should the JWT callback contain? I don't understand how to update the session with accessTokenExpired etc. |
Beta Was this translation helpful? Give feedback.
-
|
The callback does not matter for refreshing, that is just where you create your initial token and session object. The point is that refreshing in the callbacks does not work (yet) because of how Next.js with the app router works; the cookies() update() method can't set cookies directly on the server side. That is why the solution is to implement the refresh token rotation logic in middleware.ts, where requests and responses can be intercepted. When refreshing the tokens in the middleware, you need to use the same token form factor as in your callbacks. In my case, I first extended the default next-auth types: types/next-auth.d.ts: Then the callbacks of auth options: Then, you handle the refreshing of tokens in your middleware: |
Beta Was this translation helpful? Give feedback.
-
|
Спасибо! Написал под себя, все заработало. Теперь обновляет при смене фокуса + обновляет при переходе на другую страницу или при рефреш. |
Beta Was this translation helpful? Give feedback.
-
|
@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). |
Beta Was this translation helpful? Give feedback.
-
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 One possible solution would be to return an extra cookie that tells the client if it has to call the new Edit: I have just read in the docs that the
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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;
}; |
Beta Was this translation helpful? Give feedback.
-
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.
it would look like this: |
Beta Was this translation helpful? Give feedback.
-
|
i made some adjustment, when the refresh token is invalid, and I couldn't get a new access token, i just delete the cookies, so the user gets unauthenticated. import { NextMiddleware, NextRequest, NextResponse } from "next/server";
import { JWT, encode, getToken } from "next-auth/jwt";
import { BACKEND_URL } from "./lib/constants";
interface BackendTokens {
accessToken: string;
refreshToken: string;
expiresIn: number;
}
export const config = {
matcher: "/:path*",
};
const sessionCookie = process.env.NEXTAUTH_URL?.startsWith("https://")
? "__Secure-next-auth.session-token"
: "next-auth.session-token";
function signOut(request: NextRequest) {
let response = NextResponse.next();
request.cookies.getAll().forEach((cookie) => {
if (cookie.name.includes("next-auth")) response.cookies.delete(cookie.name);
});
return response;
}
function shouldUpdateToken(tokens: BackendTokens) {
if (new Date().getTime() < tokens.expiresIn) {
return false;
}
return true;
}
export const middleware: NextMiddleware = async (request: NextRequest) => {
const session = await getToken({ req: request });
if (!session) return signOut(request);
let response = NextResponse.next();
if (shouldUpdateToken(session.backendTokens)) {
// Here yoy retrieve the new access token from your custom backend
try {
const newTokens = await refreshToken(session);
const newSessionToken = await encode({
secret: process.env.NEXTAUTH_SECRET!,
token: {
...session,
backendTokens: newTokens,
},
maxAge: 604800 /* TODO: 7 days -> get from the env */,
});
response = updateCookie(newSessionToken, request, response)
} catch (error) {
response = updateCookie(null, request, response)
}
}
return response;
};
async function refreshToken(token: JWT): Promise<BackendTokens> {
const res = await fetch(BACKEND_URL + "/auth/refresh", {
method: "POST",
headers: {
authorization: `Bearer ${token.backendTokens.refreshToken}`,
},
});
const response = await res.json();
if (response.statusCode == 403) {
throw new Error("RefreshTokenError");
}
console.log("refreshed", response);
return response;
}
function updateCookie(
sessionToken: string | null,
request: NextRequest,
response: NextResponse
) {
if (sessionToken) {
// set request cookies for the incoming getServerSession to read new session
request.cookies.set(sessionCookie, sessionToken);
// updated request cookies can only be passed to server if its passdown here after setting its updates
response = NextResponse.next({
request: {
headers: request.headers,
},
});
// set response cookies to send back to browser
response.cookies.set(sessionCookie, sessionToken, {
httpOnly: true,
maxAge: 604800 /* TODO: 7 days -> get from the env */,
secure: process.env.NODE_ENV === "production",
sameSite: "lax",
});
} else {
request.cookies.delete(sessionCookie);
response = NextResponse.next({
request: {
headers: request.headers,
},
});
response.cookies.delete(sessionCookie)
}
return response;
} |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
I've returned to this problem today after a long break (different project) and finally found the solution. The cookie was not set properly after a new token was generated. The 'secure' flag was missing. That was the reason why in prod environment (under https) it was not working.
|
Beta Was this translation helpful? Give feedback.
-
|
after a long search for a solution to the problem, I found a variant of writing middleware. This completely helped to solve the problem. The code is here https://www.youtube.com/watch?v=PY4gsmndQkE&t=1s |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
`import { getServerSession } from "next-auth"; export default Server;` |
Beta Was this translation helpful? Give feedback.
-
Maybe it has to do with one of the following:
For me, it's working fine in production. I've combined a few of the answers above and deployed to Azure Portal. |
Beta Was this translation helpful? Give feedback.
-
|
@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
From wherever you have authOptions available. Then you can call
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
hey @NanningR, maybe you have an idea how to solve the following problem. 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? |
Beta Was this translation helpful? Give feedback.
-
|
@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): 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone who is using Vercel for hosting, it is likely the 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 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. |
Beta Was this translation helpful? Give feedback.
-
|
@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>;
} |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
@AndrewRayCode Well, it's not really the problem of next-auth. It's a well-established library, and even ChatGPT uses it to integrate an oauth provider into their front-end (check the cookies!). The problem is with Next.js and the app router. We can't update the session using callbacks like we normally would, because Next's cookies() method, which is used by next-auth under the hood for this purpose, can only read cookies server-side. The middleware solution discussed in this thread, is a way around this. It's actually not that weird of a solution, and in fact, it's actually quite in line with Next.js's recommended way of handling authentication: https://nextjs.org/docs/pages/building-your-application/authentication. The middleware can be used for this purpose because requests and responses can be intercepted. It's just crazy that we have to implement this ourselves and figure out the best way to do this, because this problem has existed for more than a year now. It's a system-breaking bug that makes next-auth unusable without a workaround like this. In any case, if you refuse to use this solution, you can always go for the database strategy instead of the JWT strategy. When saved in a database, the session can be updated however and whenever you like. Hope this helps :) |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 I added 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 Hope it helps |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
this way I can update with the update method given. i didn't know that... |
Beta Was this translation helpful? Give feedback.
-
|
@balazsorban44 is this something new? why is it not mentioned in the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone using the latest beta version (nextauth -> authjs) you need to update the sessionCookie names to: |
Beta Was this translation helpful? Give feedback.
-
|
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 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 callbacks: {
async jwt({ user, token, account, trigger, session }): Promise<JWT> {
// ...
if (trigger === 'update') {
return {
...filteredToken,
foo: session.foo
}
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
there is already an update function https://authjs.dev/reference/next-auth#unstable_update Although it is not stable now, considering that the package is beta, we use it in an active project as if there is no harm in using it. |
Beta Was this translation helpful? Give feedback.
-
|
You're talking about an experimental feature in a beta. |
Beta Was this translation helpful? Give feedback.
-
|
Ah! Yeah, we're using v5. |
Beta Was this translation helpful? Give feedback.
-
|
@emreakdas can you demonstrate how you use unstable_update. I am using v5 and want to update the session from the server. |
Beta Was this translation helpful? Give feedback.
-
|
Hi! jwt callback; /api/refresh-token When I use rtk query etc from client and endpoint gets 401, I created an api route to handle it, but. if you are going to use it on the server, you can directly use unstable update by creating a fetch wrapper. |
Beta Was this translation helpful? Give feedback.
-
|
I do this because I can't use useSession (since it is not in an fn component) in case of socket 401 or rtk query 401. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
For some reason, when I set the new session, my user object no longer retains the fields it previously had. Heres the code I know this can't be an issue with the |
Beta Was this translation helpful? Give feedback.
and others
-
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&refreshTokenwhich 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
useSessionhook that provides theupdatemethod, I'm not sure how we can have that functionality on the server side as well.The functionality I aim for:
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
Beta Was this translation helpful? Give feedback.
All reactions