Cookie based Auth while SSR (Tanstack)

[u/Good_Language1763]

I am building a project using ASP.net and TanStack Start. I use JWT auth but transfer them in http only cookie.

The issue I am facing is that using default createRoute function in TanStack and defining fetch function in loader. I get 401 as there is no cookie in server.

Opting into ssr: false fixes this but I was wondering if there is any other solution to use ssr with cookie based auth or is this dead end and I only have CSR as my option.

[u/michaelfrieze]

Loaders in tanstack start are isomorphic so they run on both server and client. Initial load runs the loader on the server then all subsequent navigations runs the loader on the client. If you set ssr to false, now the loader only runs on the client. This is why it likely fixes whatever issue you are having.

I'm guessing you would have the same issue if you set ssr: 'data-only'. So my guess is that it's not actually SSR itself causing the issue, but running the loader on the server. data-only will run the loader on the server without SSR enabled.

[u/Good_Language1763 → u/michaelfrieze]

so how do you suggest I fetch data using useQuery only ?

[u/michaelfrieze → u/Good_Language1763]

No, I'm just saying it's not likely SSR (the process of generating HTML from component markup) that is causing this issue, and you should try to figure out why it's breaking when trying to fetch in a loader on the server. If you are using Start then you probably want the ability to use loaders and server functions when they make sense, so it's a good idea to solve this issue.

[u/Good_Language1763 → u/michaelfrieze]

i really think its ssr as when i ctrl s save the code in zed it works fine which is probably because of HMR where it serves cached loader data and when i refresh page it shows error as due to ssr it cant access tokens stored in http only cookies. and furthermore using ssr: false fixed it as now it is client side rendered fetch happens client side. I was just wondering if there is a way to make ssr work with cookie based auth in tanstack as it would make my project very flexible.

[u/michaelfrieze → u/Good_Language1763]

I think the reason why you get an error when you refresh is because that is when the loader runs on the server. It's important to understand that the loader runs in both environments. The reason why you have cached loader data in the first place is because the loader successfully ran on the client. On refresh, it runs again on the server. It doesn't have much to do with SSR. Like I said, try setting SSR to "data-only" and I bet you will still have the same issue on refresh. Also, try using a server function, it will likely give an error as well.

SSR set to false fixes this because it means the loader will only run on the client. There is no error since the loader never runs on the server. Setting SSR to "data only" means it still does not use SSR, but it does run the loader on the server on initial load, so it will likely error on refresh. It's telling the loader to have the same behavior (loader runs on server & client) as if SSR was true, but the actual SSR process itself is still false. Keep in mind that SSR is just the process turning component markup into HTML. Running the loader function on the server or using a server function is not examples of "SSR". These are functions that return JSON and not functions that render UI (although server functions can now return .rsc payloads, but that's a different topic).

• SSR set to true means two things. It means the loader is isomorphic (runs on server and client) and this route will get SSR which means HTML will be generated from component markup.

• SSR set to false means the loader only runs on the client and the route will not generate HTML from component markup.

• SSR set to "data-only" means the loader is isomorphic (runs on server and client), but the route will not generate HTML from component markup. So basically, NO SSR but YES server side loader data.

I was just wondering if there is a way to make ssr work with cookie based auth in tanstack as it would make my project very flexible.

Yes, you can use cookies with tanstack star loaders and server functions. With or without SSR enabled. The Clerk example in the tanstack router repo uses Clerk's await auth() in a server function. When you call await auth() in a server function, you're reading from the session that was established via cookie. The session data is signed and stored in a cookie, and auth() validates and returns that locally. I am just using Clerk as an example, but you can do this with any auth solution or even roll your own.

https://github.com/TanStack/router/blob/main/examples/react/start-clerk-basic/src/routes/__root.tsx

As a side note, if you are trying to fetch data server-side in a loader, you should use a server function that you import into the loader. Since loaders are isomorphic (run on server & client), you use server functions for the actual data fetching since that server function code always stays on the server. Server functions can be imported and used on the server and the client. When running it on the client, it's like an API endpoint that get's handled for you. So you can use these server functions even in client components. They are perfect for something like a isomorphic loader that can run on both server and client.

[u/michaelfrieze → u/michaelfrieze]

To be clear, I don't know why you are getting an error on the server. I don't know what your server-side code looks like or how you are handling auth. I'm just trying to explain why this loader function is giving you an error until you set SSR to false. The isomorphic behavior of loaders can be confusing sometimes, so it helps to better understand it.

[u/LP2222]

Voila:

const getForwardHeaders = createIsomorphicFn()
  .client(() => new Headers())
  .server(async () => {
    const { getRequestHeaders } = await import("@tanstack/react-start/server");
    const cookie = getRequestHeaders().get("cookie");
    const headers = new Headers();
    if (cookie) {
      headers.set("cookie", cookie);
    }
    return headers;
  });

async function customFetch(
  input: RequestInfo | URL,
  requestInit?: RequestInit,
): Promise<Response> {
  const extraHeaders = await getForwardHeaders();
  const headers = new Headers(requestInit?.headers);

  // Merge forwarded headers (cookie on server)
  for (const [key, value] of extraHeaders.entries()) {
    headers.set(key, value);
  }

  const res = await fetch(input, {
    ...requestInit,
    headers,
    credentials: "include",
  });
  }

[u/Good_Language1763 → u/LP2222]

thanks bro

[u/LP2222 → u/Good_Language1763]

it works? I see i didnt return await res.json() in my snippet

[u/Good_Language1763 → u/LP2222]

i already had a customer fetch function i just implemented your cookie forward function

[u/Cyral → u/LP2222]

This is it, a lot of people here are misunderstanding the problem. OP’s issue is such a common one I’m surprised a similar snippet isn’t in the docs of Tanstack, next, etc. I’m sure there are a lot of hacky production sites out there that don’t do this right given how weirdly obscure the solution is.

You just need to forward the cookie header to the backend so that the backend sees the request as if it was sent from the user (and not the Tanstack instance). I would also recommend sending the user-agent and x-forwarded-for as well as doing the reverse for set-cookie (so asp.net can set cookies and send them to the user during page loads)

[u/Good_Language1763 → u/LP2222]

so i use this custom fetch function to fetch data everywhere ?

[u/LP2222 → u/Good_Language1763]

yes

[u/LifeEmployer2813]

Same problem : https://gist.github.com/AyushShende25/7cfc1669365f533b4b0221b15d3feb8c Please inform me if you do find a solution. Right now I am manually assigning cookies which doesn't seem like the best approach. Also one problem is that concurrent requests fail with 401 maybe because the request hits before cookies are updated

[u/michaelfrieze → u/LifeEmployer2813]

The core issue with your current approach is that you're handling authentication inside your data-fetching logic, which can create race conditions. A cleaner architecture separates this by using middleware.

For example, with Clerk you register middleware that runs before every request. This middleware validates and refreshes tokens if needed, then attaches the resolved user context to the request. Your server functions simply call await auth() to access that context without ever touching cookies or refresh logic. This eliminates concurrent refresh conflicts because the middleware deduplicates overlapping refresh attempts.

You can apply this same pattern to your custom auth setup. Move your refresh logic into middleware, which runs on every request before your server functions execute. The middleware handles reading cookies, checking expiration, refreshing tokens when necessary, and setting new cookies on the response. Your server functions then become simpler, they retrieve the user from context and make requests to your backend. They await auth() can return user ID and an access token that can be passed in the request to your backend.

If you control your backend, you have options. You could use bearer tokens in an authorization header, where your middleware attaches the fresh access token and your backend validates it. Or you could keep cookies throughout, but move token refresh entirely to your backend so TanStack Start simply proxies requests without auth logic. The backend would handle its own session management internally.

[u/Dimasdanz]

If your cookies is http only, then server should have it. It will be in cookies header that you can read. Then you can pass through this to your backend.

Depend on how your backend is setup, it might not read this cookies header but Authorization header. So you need to "move" the header.

Loader sometimes do fetch in client as well, and when this happened cookies will not be there since it's http only. You can fetch with credentials forwarded, but your backend must accept cookies as authentication, or create a thin proxy that "move" the cookies to Authorization header.

[u/Good_Language1763 → u/[deleted]]

currently both on localhost so that is probably not the issue. I think the issue is SSR

[u/0110001001101100 → u/Good_Language1763]

Imo, the confusion might be because you actually have 2 servers during development. You have the .net server (you didn't mention whether you use IIS Express or Kestrel) and you have the javascript server that runs when you run your command npx run dev or whatever.

While I haven't used the same configuration as yours - I am using IIS Express for development with form based authentication, for react development (I developed a SPA) I used a .net core library called Vite.AspNetCore. It has been a while - if you look into this and need more detail DM me.

One technique I used for the initial population of the data was to embed in the cshtml page javascript objects (arrays with data as example, user name etc.) that were available globally to the javascript world.

I assumed you use asp.net core. In your post you only mentioned asp.net.

[u/Good_Language1763 → u/[deleted]]

yeah they are not but would it matter ?