RTK Query + Redux + Next.js 15 Authentication Flow Issue (Session Hydration Delay)
Unanswered
Neotropic Cormorant posted this in #help-forum
Neotropic CormorantOP
quick question regarding auth in Next.js 15 + Redux Toolkit
So I’ve got a setup where after login, the accessToken is stored in cookies, and then on each app load I call a GET /me endpoint to fetch the current user. That response is used to dispatch a userSignin action to update my Redux auth slice with the session info.
Now here's the issue — the page is rendering before the session data is available in Redux, so my route protection logic (which checks if isAuth is true or if user exists) runs too early and ends up redirecting to /signin even though there's actually a valid session in the cookie.
This only happens on the initial load — once the data is in Redux everything behaves normally.
Anyone else faced something similar? I’m using:
Next.js 15 App Router
Redux Toolkit + RTK Query
Cookie-based auth
Client-side route guard using HOC
Thinking of either:
Adding a loading state until the session is fully hydrated, or
Moving some of this logic into middleware for earlier control
Would love to hear how others are handling this!
So I’ve got a setup where after login, the accessToken is stored in cookies, and then on each app load I call a GET /me endpoint to fetch the current user. That response is used to dispatch a userSignin action to update my Redux auth slice with the session info.
Now here's the issue — the page is rendering before the session data is available in Redux, so my route protection logic (which checks if isAuth is true or if user exists) runs too early and ends up redirecting to /signin even though there's actually a valid session in the cookie.
This only happens on the initial load — once the data is in Redux everything behaves normally.
Anyone else faced something similar? I’m using:
Next.js 15 App Router
Redux Toolkit + RTK Query
Cookie-based auth
Client-side route guard using HOC
Thinking of either:
Adding a loading state until the session is fully hydrated, or
Moving some of this logic into middleware for earlier control
Would love to hear how others are handling this!
18 Replies
@Anay-208 | Ping in replies you can use router.refresh() on the client, or just set cookies on server action to do it automatically
Neotropic CormorantOP
Even with router.refresh(), I'm still facing the same issue — the route protection runs before Redux has the session data, so the redirect to /signin still happens. It’s not resolving properly yet. For now, I’m using a full page reload, but I’m definitely looking for a cleaner solution to avoid the flicker and premature redirect.
@Anay-208 | Ping in replies I would recommend instead of using redux, just create a hook to get session in client side, to directly check cookie
Neotropic CormorantOP
My client and server are on different origins. When I send a login request to the server, the browser automatically sets a cookie. At that point, the server that's part of the Next.js app makes a request, sets the cookie, and then uses that cookie in middleware.ts to handle route protection.
I’ve come up with this logic and I’m hoping it will work as expected. It seems like the default flow using Next.js 15+ with Redux and Redux Toolkit doesn't handle this scenario well out of the box.
I’ve come up with this logic and I’m hoping it will work as expected. It seems like the default flow using Next.js 15+ with Redux and Redux Toolkit doesn't handle this scenario well out of the box.
So why don't you just get the cookie to check for auth in client compoment?
@Anay-208 | Ping in replies So why don't you just get the cookie to check for auth in client compoment?
Neotropic CormorantOP
Because the cookie is marked as HttpOnly, it’s not accessible via JavaScript on the client side. That’s why I can’t directly check it in a client component — I have to rely on the server (or middleware) to read the cookie and handle auth validation.
@Neotropic Cormorant Because the cookie is marked as HttpOnly, it’s not accessible via JavaScript on the client side. That’s why I can’t directly check it in a client component — I have to rely on the server (or middleware) to read the cookie and handle auth validation.
It can make an api request to server to get auth status
@Anay-208 | Ping in replies It can make an api request to server to get auth status
Neotropic CormorantOP
Yes, that's true, the client can make an API request to the server (like a /me endpoint) to get the auth status. And that's actually what I'm doing. But the issue is that this check happens after the initial render, so if I rely on Redux for auth state, the route protection logic may run too early,before the session is available, causing unwanted redirects. That’s why I’m exploring ways to handle it earlier, like in middleware or on the server side.
Wait, how does your route protection logic work?
I'm a little puzzled, shouldn't it just access from the cookie?
I'm a little puzzled, shouldn't it just access from the cookie?
@Anay-208 | Ping in replies Wait, how does your route protection logic work?
I'm a little puzzled, shouldn't it just access from the cookie?
Neotropic CormorantOP
I'm using a client-side HOC that checks Redux state for auth. Even though the cookie is there, Redux doesn't have the user data right away because it fetches it after render. So the route guard runs too early and redirects. This approach used to work fine in Next.js 14, but it's not working the same way in Next.js 15, that’s why I’m thinking of handling auth in middleware instead.
@Anay-208 | Ping in replies Where exactly is the route guard running?
Neotropic CormorantOP
The route guard is running inside a client-side higher-order component (HOC) that wraps protected pages. It checks the Redux state to see if the user is authenticated. The issue is that Redux doesn’t have the user data immediately on first load, so the guard runs too early and triggers a redirect, even though the session is valid in the cookie.
@Neotropic Cormorant The route guard is running inside a client-side higher-order component (HOC) that wraps protected pages. It checks the Redux state to see if the user is authenticated. The issue is that Redux doesn’t have the user data immediately on first load, so the guard runs too early and triggers a redirect, even though the session is valid in the cookie.
The flow seems to complex.
What can be done is move route guard to middleware, which will resolve everything.
What can be done is move route guard to middleware, which will resolve everything.
Neotropic CormorantOP
I’ve resolved it using a different approach, maybe the previous method just doesn’t work properly in this version.
@Anay-208 | Ping in replies Can I know what approach did you take
Neotropic CormorantOP
Yeah, so I moved the session check to the server side using middleware.ts, where the cookie is accessible directly. That way, I can handle route protection before the page renders, avoiding the early redirect issue I was facing with the client-side HOC. It works much more reliably in this setup. https://nextjs.org/docs/app/building-your-application/routing/middleware
@Anay-208 | Ping in replies The flow seems to complex.
What can be done is move route guard to middleware, which will resolve everything.
Yup, that’s what I suggested here.
Can you mark solution
Can you mark solution
@Anay-208 | Ping in replies Yup, that’s what I suggested here.
Can you mark solution
Neotropic CormorantOP
This approach works if the Next.js server and client are on the same origin. But since the Next.js server and the main backend server are on different origins, I’m planning to make an API request from the client to the main server and then set the cookie via that request. https://nextjs.org/docs/pages/guides/authentication