Replies: 1 comment
|
The callback is updating the in-memory JWT for that one session lookup, but the updated JWT is not being persisted back to the browser's session cookie in the request path you are using. The logs make that visible: every request starts again with the same old access token and the same old refresh token, performs another refresh, and obtains a different replacement. A page reload works because it causes a request through the Auth.js session endpoint/client session flow, where the response can actually send a If these calls originate while rendering a Server Component, I would restructure this as follows:
return {
...token,
accessToken: response.accessToken,
refreshToken: response.refreshToken ?? token.refreshToken,
expiresAt: response.expiresAt,
}There are also two security fixes I would make immediately:
So this is not a TypeScript augmentation problem, nor is mutating If this resolves the repeated-old-token behavior, please mark it as the accepted answer so future readers can find it quickly. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey all, this has been driving me absolutely insane lately trying to figure out whats going on. For some reason, when the JWT callback on my app runs, and the access/refresh token is refreshed, its not actually updating the properties on the token, user and session objects. Weirdly enough - if I refresh the actual page, the tokens seem to update perfectly fine, this only doesn't work when the JWT callback updates naturally or by making requests
auth-options.ts:
next-auth.d.ts:
Logs:
From the logs, we can clearly see that the old refresh/tokens are still being used in subsequent requests - does anyone have any ideas on this? I'm using getServerSession to make the calls from my frontend server to my backend server.
All reactions