Tokens rotation does not persist the new token #7558
Comments
mrbodich
added
the
triage
|
similiar problem is stated in #6642 . Sadly it seems like noone cares about this issue atm, altough its a system breaking problem. |
balazsorban44
added
the
incomplete
|
We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate. Why was this issue marked with the
|
|
Hello @balazsorban44. I've deployed Keycloak, made necessary setup and pushed my example based on the latest example repo fork to github. Alternatively, I've updated the main question, section Reproduction URL and How to reproduce You can find the credentials to login in the .env.local.example file, along with other necessary env variables, so just transfer this file to the .env.local file. Updated issue descriptionI've found more details. Look at this file in my repo. Tokens are rotating fine if you will comment lines 18 ... 25 |
@Mikk36 I disagree. As the author of referred discussion the problem is described with JWT tokens and not database strategy and problem seems to remain also we newer versions (its true that i haven't tested with latest version). |
balazsorban44
removed
the
incomplete
My bad, I mixed up discussion numbers and thought it was something else. |
|
@mrbodich Instead of using |
I have tried this and getting such error on backend |
|
@mrbodich That is not related to Please check PR - mrbodich/next-auth-example-fork#1 for detailed code. |
Thank you @anampartho, I got the idea now. Just was confused why it worked without server session handling. Can I ask you to give me a very important tip that I can't understand please? How can I use getServerSession not only in the root '/' route (or on each route separately), but on the very top level so all routes will inherit that? And how is it possible to add extra properties on the lower levels or sub-routes? Adding |
By the way, I came up with this solution. Updated provider's PS: Thank you so much for your help. |
@mrbodich Unfortunately, you have to use |
|
I am using getServerSession in the app directory, but the problem stil occurs. But I guess the problem is because of the following issue stated by this user: #6642 (comment) |
@osmandvc Do you have a workaround for that? |
Sadly I did not find a really convenient way without too much overhead to make it work with RSC. The only solution currently seems like to switch to traditional client-side Authentication with useSession and a SessionProvider. |
Could you give me an example? |
|
Any progress with this bug? I cannot implement token refreshing with next auth. After login i getting new set of tokens and first refreshing is ok but when i get new set the old tokens are not updated and next refresh call gives me error.
|
|
I also have this problem with Since sveltekit does prefetching when hovering links it triggers an awful lot of "token refreshes" after the first access token expires. |
I use keycloack and I manage to make the token refresh a few seconds before it expires but the getsesion still gets the old token but when I refresh the browser tab with f5 it gets the refreshed token, I am trying to do something to observe this change, like a useeffect. import NextAuth, { KeycloakTokenSet, NextAuthOptions } from "next-auth";
import { JWT } from "next-auth/jwt";
import KeycloakProvider from "next-auth/providers/keycloak";
const keycloak = KeycloakProvider({
clientId: process.env.KEYCLOAK_ID,
clientSecret: process.env.KEYCLOAK_SECRET,
issuer: process.env.KEYCLOAK_ISSUER,
authorization: { params: { scope: "openid email profile offline_access" } },
});
async function doFinalSignoutHandshake(token: JWT) {
if (token.provider == keycloak.id) {
try {
const issuerUrl = keycloak.options!.issuer!;
const logOutUrl = new URL(`${issuerUrl}/protocol/openid-connect/logout`);
logOutUrl.searchParams.set("id_token_hint", token.id_token);
const { status, statusText } = await fetch(logOutUrl);
console.log("Completed post-logout handshake", status, statusText);
} catch (e: any) {
console.error("Unable to perform post-logout handshake", e?.code || e);
}
}
}
function parseJwt(token: string) {
return JSON.parse(Buffer.from(token.split(".")[1], "base64").toString());
}
async function refreshAccessToken(token: JWT): Promise<JWT> {
try {
// We need the `token_endpoint`.
const response = await fetch(
`${keycloak.options!.issuer}/protocol/openid-connect/token`,
{
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
client_id: keycloak.options!.clientId,
client_secret: keycloak.options!.clientSecret,
grant_type: "refresh_token",
refresh_token: token.refresh_token,
}),
method: "POST",
}
);
const tokensRaw = await response.json();
const tokens: KeycloakTokenSet = tokensRaw;
// console.log(tokensRaw)
if (!response.ok) throw tokens;
const expiresAt = Math.floor(Date.now() / 1000 + tokens.expires_in);
console.log(
`Token was refreshed. New token expires in ${tokens.expires_in} sec at ${expiresAt}, refresh token expires in ${tokens.refresh_expires_in} sec`
);
const newToken: JWT = {
...token,
access_token: tokens.access_token,
refresh_token: tokens.refresh_token,
id_token: tokens.id_token,
expires_at: expiresAt,
provider: keycloak.id,
};
return newToken;
} catch (error) {
// console.error("Error refreshing access token: ", error)
console.error("Error refreshing access token: ");
throw error;
}
}
// For more information on each option (and a full list of options) go to https://next-auth.js.org/configuration/options
export const authOptions: NextAuthOptions = {
secret: process.env.NEXTAUTH_SECRET,
// https://next-auth.js.org/configuration/providers/oauth
providers: [keycloak],
theme: {
colorScheme: "light",
},
pages: {
signIn: "/login",
signOut: "/login",
},
callbacks: {
async jwt({ token, account, user }) {
console.log("Executing jwt()");
if (account && user) {
const jwtDecoded = parseJwt(account.access_token as string);
if (!account.access_token)
throw Error("Auth Provider missing access token");
if (!account.refresh_token)
throw Error("Auth Provider missing refresh token");
if (!account.id_token) throw Error("Auth Provider missing ID token");
// Save the access token and refresh token in the JWT on the initial login
const newToken: JWT = {
...token,
access_token: account.access_token,
refresh_token: account.refresh_token,
id_token: account.id_token,
expires_at: Math.floor(account.expires_at ?? 0),
provider: account.provider,
userName: jwtDecoded.preferred_username,
userRoles: jwtDecoded.resource_access.account.roles,
};
return newToken;
}
const timeRemaining = token.expires_at * 1000 - Date.now();
if (timeRemaining > 30000) {
// If the token's remaining time is greater than 30 seconds, return the current token
console.log(
`\n>>> ${timeRemaining / 1000} seconds left until token expires`
);
return token;
}
console.log(`\n>>> Old token expired`);
// If the access token has expired or will expire within 30 seconds, try to refresh it
const newToken = await refreshAccessToken(token);
console.log(`New token adquired: ${newToken.expires_at}`);
return token;
},
async session({ session, token }) {
console.log(`Executing session() with token ${token.expires_at}`);
// You need to set the user object properly in jwt callback,
// Error: Error serializing .session.user.image was occuring because
// session.user.image was undefined, it needs to be value || null
session.user = { ...token };
return { ...session };
},
},
events: {
signOut: async ({ session, token }) => doFinalSignoutHandshake(token),
},
jwt: {
// maxAge: 60, // 20 horas
maxAge: 32400, // 9h
},
session: {
// maxAge: 30 * 24 * 60 * 60, // 30 days : 2592000, same as in Keycloak
maxAge: 32400, // 9h
},
};
export default NextAuth(authOptions);API: import { NODE_ENV, uri } from "@/constants/environment-variables";
import axios, { AxiosInstance, AxiosRequestConfig } from "axios";
const axiosInstance = axios.create({
baseURL: uri[NODE_ENV],
});
async function getData() {
const res = await axios.get("/api/auth/session");
return res;
}
const setAuthorizationHeader = async (axiosInstance: AxiosInstance) => {
// You can try to get the access token that way
const session = await getData();
// Or you can try to use Next Auth function
// const session = getSession()
// if I'm on the /api/auth/session page and I press f5 to refresh the tab, the new access token is there,
// however, neither getData() nor getSession() remains the previous access token, they will only update,
// if I refresh the page. I believe that useeffect solves it but I still don't know how to do it
console.log(session);
if (session) {
const token = session.data.user.access_token;
console.log(session);
axiosInstance.interceptors.request.use((config) => {
config.headers.Authorization = `Bearer ${token}`;
return config;
});
}
};
setAuthorizationHeader(axiosInstance);
const api = (axios: AxiosInstance) => {
return {
get: function <T>(url: string, config: AxiosRequestConfig = {}) {
return axios.get<T>(url, config);
},
put: function <T>(
url: string,
body: unknown,
config: AxiosRequestConfig = {}
) {
return axios.put<T>(url, body, config);
},
post: function <T>(
url: string,
body: unknown,
config: AxiosRequestConfig = {}
) {
return axios.post<T>(url, body, config);
},
delete: function <T>(url: string, config: AxiosRequestConfig = {}) {
return axios.delete<T>(url, config);
},
};
};
export default api(axiosInstance); |
I did it similar to this comment: #5647 (comment) . Basically follow the Tutorial on the Nextauth-Page, the only thing that changes is where you put your SessionProvider. Make a seperate Client-Component put your Provider there, and wrap your Content in your Root-Layout with the newly created Client-Component. This way you make sure that the layout.tsx remains a Server-Component. Now every underlying page has Access to the Session-Object (mostly with delay, because client-side) |
|
As of authjs@5.0 (experimental), this is still an occurring issue. The initial token is stored; however, going forward, updates made to it are never saved (at least not to the token that is provided within Due to this issue, refresh token rotation is in practice, not possible with auth.js :( Edit 1: Edit 2: However, when using something like As such, there is much that can be done currently, until Next makes it possible to set cookies sitewide. Edit 3: |
|
Hi @balazsorban44 , refresh token rotation seems to be broken. Do you know if there is a plan to fix this issue? Is someone looking into it? |
|
Have a look at the issue here: #4229. Managed to get it work using update() from the useSession hook. |
|
It seems, that token rotation actually theoretically works when using auth.js When using token rotation after a login I noticed, that after a redirect it calls Auth again on /api/auth/session. I am using qwik-auth so I can only compare to that. It seems, that qwik-auth makes an exception when manually calling /api/auth/session and does not set the 'set-cookie' after a successful response. Following I will describe what happens in qwik-auth, but I assume that the issue is similar with other implementations. The issue is, that the updated cookie is not received by the client, since qwik-auth works like this: Context: const actions: AuthAction[] = [
'providers',
'session',
'csrf',
'signin',
'signout',
'callback',
'verify-request',
'error',
];onRequest: const onRequest = async (req: RequestEvent) => {
if (isServer) {
const prefix: string = '/api/auth';
const action = req.url.pathname.slice(prefix.length + 1).split('/')[0] as AuthAction;
const auth = await authOptions(req);
// We notice, that there is no action that is named like so and neither is the prefix present.
if (actions.includes(action) && req.url.pathname.startsWith(prefix + '/')) {
const res = await Auth(req.request, auth);
const cookie = res.headers.get('set-cookie');
if (cookie) {
req.headers.set('set-cookie', cookie);
res.headers.delete('set-cookie');
fixCookies(req);
}
throw req.send(res);
} else {
// So this gets triggered and getSessionData(...) does not set the cookies on response.
req.sharedMap.set('session', await getSessionData(req.request, auth));
}
}
};The fix I did is here: https://github.com/BuilderIO/qwik/pull/4960/files |
|
Ok so I took some time just looking at the react code, but since I don't use react I cannot confirm. Hopefully somebody can confirm this for me: 1. Get Session gets called:
2. fetchData gets called:
If Probably triggered here: |
|
So what's needed is a way to have the cookie being pushed on any request, not just |
|
Sounds like you can just use a middleware. On every request initiated in protected routes, fetch to |
|
@rinvii ofc that would work, but then you also have to call signin manually since after signin the jwt rotation gets triggered again since session is called and at that point you are building your own implementation of /next-auth/src/react/index.ts I am assuming that react/index.ts is the same like https://github.com/BuilderIO/qwik/blob/47c2d1e838e9f748b191e983dabb0bac476f8083/packages/qwik-auth/src/index.ts // Disclaimer: |
|
@aliyss I don't think calling sign in is necessary in order to solve the token rotation issue. While you can and should call sign in when you are authenticating, subsequent authorizations do not need to call sign in. I don't know if I understood the point you were making. Is there anything preventing you from configuring the session callback to return new access tokens when needed? Note the source code describes the jwt callback as follows: /**
* This callback is called whenever a JSON Web Token is created (i.e. at sign in)
* or updated (i.e whenever a session is accessed in the client).
* Its content is forwarded to the `session` callback,
* where you can control what should be returned to the client.
* Anything else will be kept from your front-end.
*
* The JWT is encrypted by default.
*
* [Documentation](https://next-auth.js.org/configuration/callbacks#jwt-callback) |
* [`session` callback](https://next-auth.js.org/configuration/callbacks#session-callback)
*/Therefore, forward access tokens to the session callback. In order to rotate the tokens, you have to update the cookies. You can do this by forwarding the response from the session callback as new cookies. This can be done through middleware. Note: reading through past comments, there seems to be a fundamental misunderstanding on how getServerSession works. This function cannot update the session; it can only validate the session. If you're wanting to update the session, do it through the client (as @walshhub did) or middleware. |
|
Middleware example: #8254 (comment) |
I think we are talking past each other on some topics, so I will kind of clarify it.
I can't make a comment on that, but I'm talking about getSession in Although looking at that it seems the cookies are updated as well: next-auth/packages/next-auth/src/next/index.ts Lines 220 to 222 in 9c6f813 In the case of the example for the token rotation described here: https://authjs.dev/guides/basics/refresh-token-rotation#jwt-strategy This function gets called here: Then the refresh-token is triggered. But on reloading the page the cookies have not updated. So when it is called again it still uses the old token. |
|
@rinvii Basically what I want to say is calling /api/auth/session, may update the token if calling it and not catching the cookies of the response, this can lead to an invalid token rotation on the second call. I see that it is recommended to use getServerSession https://next-auth.js.org/configuration/nextjs#getserversession But let's say we call signin described here: ...few lines later... next-auth/packages/next-auth/src/react/index.tsx Lines 279 to 281 in 9c6f813 Probably triggers this: next-auth/packages/next-auth/src/react/index.tsx Lines 367 to 376 in 9c6f813 Which triggers this: next-auth/packages/next-auth/src/react/index.tsx Lines 161 to 167 in 9c6f813 Then triggers this (url being next-auth/packages/next-auth/src/client/_utils.ts Lines 52 to 55 in 9c6f813 And now it's based on what I said in my first response. |
Thanks!
getServerSession is called (ideally) in react server components. Only the body is returned or null otherwise. Looking at your referenced code, that line that sets the cookie literally doesn't do anything. And from what I understand about RSC, cookies cannot be set at all in a RSC.
You could return the new refresh/access token in the session callback. From the middleware, initiate requests to |
This was a little bit misleading. I'm speaking in the context of Next.js app router in that you can't update the session. In pages router, you could probably update. |
|
This answers it?
I am thinking of using some kind of persistent storage option to store tokens and other metadata (refresh token, expiry time). Then again the problem starts with latency to get token data from storage? |
|
The problem is present in sveltekit as well |
|
Any updates on this issue? |
|
This might very well be fixed in Sveltekit as of version 0.8.0 of https://github.com/nextauthjs/next-auth/releases/tag/%40auth%2Fsveltekit%400.8.0 |
|
I found out that the session wasn't updating after an api request. After digging a lot, I've found this: Call update() in your client after making the API call and it'll sync the backend session with your cookies and you'll now have the new AccessToken and RefreshToken. |
|
@rohanrajpal @diegogava @eirik-k @karlbessette A solution is to use middleware.ts, as it's inline with the official next.js docs: https://nextjs.org/docs/pages/building-your-application/authentication Solution available here (hats off to the guy Rinvii who first came up with it): #9715 In short, you implement the refresh token rotation logic in middleware, and force getServerSession() to read the new session and send it back to the browser by setting the cookies. You do something like this: import { NextResponse, type NextMiddleware, type NextRequest } from "next/server";
import { encode, getToken, type JWT } from "next-auth/jwt";
import {
admins,
SESSION_COOKIE,
SESSION_SECURE,
SESSION_TIMEOUT,
SIGNIN_SUB_URL,
TOKEN_REFRESH_BUFFER_SECONDS
} from "./config/data/internalData";
let isRefreshing = false;
export function shouldUpdateToken(token: JWT): boolean {
const timeInSeconds = Math.floor(Date.now() / 1000);
return timeInSeconds >= token?.expires_at - TOKEN_REFRESH_BUFFER_SECONDS;
}
export async function refreshAccessToken(token: JWT): Promise<JWT> {
if (isRefreshing) {
return token;
}
const timeInSeconds = Math.floor(Date.now() / 1000);
isRefreshing = true;
try {
const response = await fetch(process.env.AUTH_ENDPOINT + "/o/token/", {
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
client_id: process.env.CLIENT_ID,
client_secret: process.env.CLIENT_SECRET,
grant_type: "refresh_token",
refresh_token: token?.refresh_token
}),
credentials: "include",
method: "POST"
});
const newTokens = await response.json();
if (!response.ok) {
throw new Error(`Token refresh failed with status: ${response.status}`);
}
return {
...token,
access_token: newTokens?.access_token ?? token?.access_token,
expires_at: newTokens?.expires_in + timeInSeconds,
refresh_token: newTokens?.refresh_token ?? token?.refresh_token
};
} catch (e) {
console.error(e);
} finally {
isRefreshing = false;
}
return token;
}
export function updateCookie(
sessionToken: string | null,
request: NextRequest,
response: NextResponse
): NextResponse<unknown> {
/*
* BASIC IDEA:
*
* 1. Set request cookies for the incoming getServerSession to read new session
* 2. Updated request cookie can only be passed to server if it's passed down here after setting its updates
* 3. Set response cookies to send back to browser
*/
if (sessionToken) {
// Set the session token in the request and response cookies for a valid session
request.cookies.set(SESSION_COOKIE, sessionToken);
response = NextResponse.next({
request: {
headers: request.headers
}
});
response.cookies.set(SESSION_COOKIE, sessionToken, {
httpOnly: true,
maxAge: SESSION_TIMEOUT,
secure: SESSION_SECURE,
sameSite: "lax"
});
} else {
request.cookies.delete(SESSION_COOKIE);
return NextResponse.redirect(new URL(SIGNIN_SUB_URL, request.url));
}
return response;
}
export const middleware: NextMiddleware = async (request: NextRequest) => {
const token = await getToken({ req: request });
const isAdminPage = request.nextUrl.pathname.startsWith("/epa");
const isAuthenticated = !!token;
let response = NextResponse.next();
if (!token) {
return NextResponse.redirect(new URL(SIGNIN_SUB_URL, request.url));
}
if (shouldUpdateToken(token)) {
try {
const newSessionToken = await encode({
secret: process.env.NEXTAUTH_SECRET,
token: await refreshAccessToken(token),
maxAge: SESSION_TIMEOUT
});
response = updateCookie(newSessionToken, request, response);
} catch (error) {
console.log("Error refreshing token: ", error);
return updateCookie(null, request, response);
}
}
if (isAdminPage && isAuthenticated && !admins.includes(token.email!)) {
return NextResponse.redirect(new URL("/forbidden", request.url));
}
return response;
};
export const config = {
matcher: ["/dashboard/:path*", "/epa/:path*"]
};Make sure you read all the comments on the references page to apply this to your situation |
|
When adjusted to a custom codebase, @NanningR answer is a great starting point, though there are some settings which need to be done like secrets and salts. |
|
I'm using I've managed to solve this problem with wrapping the root layout with "use client";
import { SessionProvider } from "next-auth/react";
import React, { ReactNode } from "react";
export const SessionProviderWrapper = ({
children,
}: {
children?: ReactNode;
}) => {
return <SessionProvider>{children}</SessionProvider>;
};import { getServerSession } from "next-auth/next";
import { Nav } from "@/app/ui/Nav/Nav";
import { SessionProviderWrapper } from "@/app/lib/Providers";
import { authOptions } from "@/auth";
export default async function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
const session = await getServerSession(authOptions);
return (
<SessionProviderWrapper>
<html lang="en">
<body>
<Nav isLoggedIn={!!session} />
{children}
</body>
</html>
</SessionProviderWrapper>
);
} |
|
This is also happening with nextjs 14 and the new authjs 5 beta - using only the client side it will work, but whenever the token is refreshed through the middleware it is not updated to the client! The next request then still uses the old session. |
|
Because of this, I gave up on using next auth. |
|
This is still a problem. There is no way to update the session on the server side |
|
@HenrikZabel I literally mentioned it here: #7558 (comment) And it is discussed in detail here: #9715 @jarosik10 @wodka @wonkyDD The point is that you don't ever need things like SessionProvider when using next-auth and the middleware trick to update the session on server side. In fact, when using Next.js server components, you should completely avoid any client-side functions such as useSession(). You only focus on the server side, refresh the tokens there, and pass the session from server components down to client-components as props: I can guarantee you that this works when implemented correctly. This method is actually quite in line with Next.js's official documentation on authentication: https://nextjs.org/docs/pages/building-your-application/authentication. It's just crazy that we have to figure out the best way to do this ourselves. |
|
@NanningR I am using v5. I thought about just manually calling |
|
@NanningR next-auth docs (which are not great) shows that refresh token rotation should be handled inside jwt callback delcared in next-auth configuration. https://authjs.dev/guides/refresh-token-rotation I haven't tried to handle the rotation inside middleware yet. But yeah, i agree that looking for the right approach (with poor docs) is kinda annoying. |
|
@jarosik10 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 (explained here: #9715 (reply in thread) and here: #9715 (reply in thread)). The 'official' docs are hopelessly unclear, which is also the case for the page you just sent me, even though it got updated recently. Before #9715 existed, we were discussing here: #8254. It then got converted into the new discussion by the official maintainer:
For some reason, they refuse to be clear in the docs. I think they have just not found a clean way to implement this for server components, so they are silent about the issue. I recommend you try the middleware solution. It is a bit of a hassle to set up, but works flawlessly once implemented. 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 :) @HenrikZabel I'm not using v5 myself yet because it is still in beta and as such not ready for production. However, a bunch of people in the discussion I linked to have successfully implemented this using the new v5. |
and others
Environment
When rotating tokens, new token is not stored and thus not reused, so token is lost. The old token still persists instead and used for all further iterations of current session.
Only initial token generated on login works and reused constantly.
I use Keycloak as the external IDP
Keycloak — 21.1.1
Nextjs — 13.4.2
Next-auth — 4.22.1
Node — 16.2.0, 19.9.0
Reproduction URL
https://github.com/mrbodich/next-auth-example-fork.git
Describe the issue
When I use
async jwt()function incallbackssection, I get the new token from external IDP successfully, create the new token object and return inasync jwt()just like documentation says.Here is my piece of code in the last
elseblock (if access token is expired)Once token expired, and
elseblock is executed, I have constantly updating at each request. Here is what I get in the console logged:As you see,
1684147058is not changed between requests, so new JWT is just lost somewhere and not used for later requests. Though at the first login, returned jwt is used correctly.How to reproduce
.env.local.examplefile to.env.local file.env.local.examplefile,row 1318 ... 25in theindex.tsxfile (getServerSideProps function), and tokens will start rotating fine.Expected behavior
Token returned in the
async jwt()function incallbackssection must be used on the next request and not being lost.The text was updated successfully, but these errors were encountered: