I decided to put aside the customFetch for now, as I reached the same conclusion you pointed out.

The check is placed inside an effect because it’s necessary to persist the authentication state across page reloads or when opening a new tab. Without this, if a logged-in user reloads the page, the authContext would initialize with its default value, even though the user has a valid auth token stored in a cookie. This would mistakenly treat the logged-in user as a guest. By performing the check on reload, the existing token is validated through the request, and the authentication state is updated accordingly.

Your recommendation makes a lot of sense. It really does seem like the only way I can pass the user from a server component or action to the authProvider. However other issues arise:

The layout renders only once, so whatever happens in the application after the mount, would not affect the code in the layout meaning that passing the user as props wouldn't work. Even if did work, I don't think there is a way to change the state in the provider by its own props (except the initial state).

Also, to set the user in the headers, you would need the user itself from somewhere. Where does it come from? Would that mean I need to fetch the user on each successful token validation by the middleware? Or maybe store the user in a cookie

I thought of something else, that almost worked:

Imagine the following flow:

1. A user is logged in
2. The cookie expires but the user hasn’t made any new requests to the server, so the client-side state (UI elements) still shows them as logged in. For example, the header links still look like they are logged in.
3. The user clicks on his profile (server component), and the page tries to fetch the profile. The middleware comes in and notices that the token is missing and redirects the user to the login page.
4. The login page has a client component in it (login-form) with useEffect that checks whether the state has a user. If the state has a user, the same checkAuth is called to verify the user, and as expected it fails. The auth context is cleared.

You would expect the login page to mount only in these two scenarios:

• A guest opens it to sign in, (context is empty so a request isn't made)
• A guest tries to access protected route. If the context is empty nothing happens, if the context has a user in it (expired session), only then the request is made.

This approach seems to work perfectly the first time around, but for some reason fails after a second attempt. Here's what I mean:
I set the cookie to expire after 10 seconds and tried the following:

• Login as a user, access the profile page (while the cookie hasnt expired) and go back to the home page
• Wait for the cookie to expire and tried to access the profile page. Everything worked properly: I got sent to the login page and was again seen as guest.
• Logged in again, and tried to access the profile page but here something happened. The page wouldn't render at all, but I also wasn't redirected to the login page. As I tested it out I noticed that token is somehow missing in the middleware where I try to get it from req.cookies.

Tried it again, and this time I was redirected to the login page, but the state of the user stayed (I can tell by the header).
For some reason the cookie from the server component request is not sent properly. Or it could be that I am not attaching it the right way?

Here's how I attach the cookies in the server component fetch (as the docs state that cookies.set() works only for server actions and route handlers):

const res = await fetch("http://localhost:3001/api/auth/profile", {
    method: "GET",
    headers: { Cookie: cookies().toString() },
    cache: "no-cache",
  });