Help with auth flows, JWT, refresh/access token and SSR (RSC)
Unanswered
Barbary Lion posted this in #help-forum
Barbary LionOP
Hi everyone,
I’m new to SSR and I’m integrating an external authentication system into Next.js. I’m using the classic setup with refresh and access JWTs: on login, a server action returns both tokens and I store them as HTTP-only cookies.
I’ve read the authentication docs multiple times, but there’s one thing I still can’t understand — and since Next.js 16 is quite new, I want to be sure I’m not missing something. Sorry if this topic has already been discussed many times, but since I haven’t found a complete architectural solution, I want to understand whether I’m going down the wrong path or inventing a non-standard authentication flow.
I can refresh the access token without issues by wrapping the default Next.js fetch. This wrapper (used in server actions or API routes) automatically refreshes the access token when it has expired and set it with cookie set. No problem there.
The issue comes when I enforce role-based restrictions.
To validate the user securely on the server, I need to call something like getSession() inside a server component. But if the access token is expired at that moment, I can refresh it, yet I cannot update the cookie with the new access token from a server component, because server components have no access to cookies set.
This is the core limitation I’m struggling with.
Many people suggest handling the refresh inside the Next.js proxy.ts file, but the official documentation seems to discourage this approach. Am I understanding that correctly?
So, if using proxy.ts for the refresh is not recommended, how are we supposed to handle access-token revalidation inside a server component?
Is this an architectural limitation of Next.js?
I was also considering using API routes triggered from proxy.ts, but is that actually a correct practice?
Should I rethink the flow?
What’s the recommended pattern when using the standard dual-JWT system (access + refresh) with an external provider like Django?
I’m new to SSR and I’m integrating an external authentication system into Next.js. I’m using the classic setup with refresh and access JWTs: on login, a server action returns both tokens and I store them as HTTP-only cookies.
I’ve read the authentication docs multiple times, but there’s one thing I still can’t understand — and since Next.js 16 is quite new, I want to be sure I’m not missing something. Sorry if this topic has already been discussed many times, but since I haven’t found a complete architectural solution, I want to understand whether I’m going down the wrong path or inventing a non-standard authentication flow.
I can refresh the access token without issues by wrapping the default Next.js fetch. This wrapper (used in server actions or API routes) automatically refreshes the access token when it has expired and set it with cookie set. No problem there.
The issue comes when I enforce role-based restrictions.
To validate the user securely on the server, I need to call something like getSession() inside a server component. But if the access token is expired at that moment, I can refresh it, yet I cannot update the cookie with the new access token from a server component, because server components have no access to cookies set.
This is the core limitation I’m struggling with.
Many people suggest handling the refresh inside the Next.js proxy.ts file, but the official documentation seems to discourage this approach. Am I understanding that correctly?
So, if using proxy.ts for the refresh is not recommended, how are we supposed to handle access-token revalidation inside a server component?
Is this an architectural limitation of Next.js?
I was also considering using API routes triggered from proxy.ts, but is that actually a correct practice?
Should I rethink the flow?
What’s the recommended pattern when using the standard dual-JWT system (access + refresh) with an external provider like Django?
1 Reply
Transvaal lion
Now don't take my word for it as i am not the best security programer. But i understand that you have a server component that needs to verify role acces. And of the token is expired / invalid it can't refresh it. Now it seems to me that the token can't become invalid as if you acces said page the webside would already refreshed the token. I handle token refreshing in the layout file and when the user opens the website it tries to refresh the token. With a Client component that is inside the layout. I think the best way it's to check if the user has the permision in the proxy.ts file and if the token is expired or smth check if the refresh token is expired if it's not let the request pass throw as. If you have the refreshing in the layout it would run and then you check does the user have the permision the acces token tels my it has. If yes continue else redirect to login page or smth. The client component can call a server action that refreshes the token and since it's called from a client component it should be able to change the cookies. Now this is mostly my oppinion about this but if something seems wrong wait for someome else or ask. I am not advanced in this field and i could make some big mistakes sequrity wise.