Fixing missing HttpOnly cookies in Blazor Server authentication

by

Summary

A developer encountered a critical issue where an HttpOnly cookie, set by a backend ASP.NET Core Web API, failed to reach the client’s browser during a Blazor Server authentication flow. While the API correctly included the Set-Cookie header in its response, the browser’s cookie jar remained empty. This is a classic architectural misunderstanding regarding the lifecycle of an HTTP request in a server-side rendering (SSR) environment.

Root Cause

The failure occurs because of a broken chain of custody for the HTTP response headers. In a Blazor Server application, the execution model is as follows:

  • The Client (Browser) initiates a SignalR connection to the Blazor Server App.
  • The Blazor Server App (acting as a server-side process) executes the HttpClient call.
  • The API sends the Set-Cookie header back to the Blazor Server App.
  • The Blazor Server App receives the header in the HttpResponseMessage object but does not automatically forward that header to the original client (the browser).

Because the HttpClient call is performed server-to-server, the browser is completely unaware that a cookie was even offered. The browser only receives what the Blazor Server sends via the SignalR circuit or the initial HTTP request, and a standard HttpClient call does not trigger a browser-level cookie update.

Why This Happens in Real Systems

This issue is common when developers treat Blazor Server like Blazor WebAssembly (WASM).

  • Client-Side vs. Server-Side Execution: In WASM, the HttpClient runs inside the browser. Therefore, when the API sends a Set-Cookie header, the browser intercepts it naturally. In Blazor Server, the HttpClient runs on the server hardware.
  • Abstraction Leaks: Developers often assume HttpClient behaves like a browser, but it is merely a low-level tool for making network requests. It lacks the built-in “Cookie Management” logic that a browser engine possesses.
  • Protocol Mismatch: Blazor Server communicates with the browser over WebSockets (SignalR). SignalR is a stateful connection, not a series of standard HTTP request/response cycles that can easily carry Set-Cookie instructions for every UI interaction.

Real-World Impact

  • Authentication Failure: Users cannot maintain sessions, leading to constant “unauthorized” errors.
  • Security Vulnerabilities: If developers attempt to bypass this by passing tokens in JSON bodies instead of HttpOnly cookies, they often inadvertently expose sensitive data to XSS (Cross-Site Scripting) attacks.
  • Increased Latency: Attempting to manually “sync” state between the server and the browser via extra API calls increases the overhead of every user action.

Example or Code (if necessary and relevant)

To fix this, you must manually extract the cookie from the API response and instruct the Blazor Server’s own response object to send it to the browser. This must happen during the initial HTTP request (e.g., during a Login POST via a standard Controller or Minimal API endpoint), as you cannot set cookies over a SignalR WebSocket.

// Inside a Blazor Server Controller or an endpoint that handles the initial Login POST
[HttpPost("login-proxy")]
public async Task ProxyLogin([FromBody] LoginRequestDTO request)
{
    // 1. Call the external API using HttpClient
    var response = await _httpClient.PostAsJsonAsync("https://api.example.com/login", request);

    // 2. Extract the Set-Cookie header from the API response
    var setCookieHeader = response.Headers.GetValues("Set-Cookie").FirstOrDefault();

    if (response.IsSuccessStatusCode && setCookieHeader != null)
    {
        // 3. Manually append the header to the Blazor Server's response to the browser
        Response.Headers.Append("Set-Cookie", setCookieHeader);
        return Ok();
    }

    return Unauthorized();
}

How Senior Engineers Fix It

Senior engineers solve this by choosing the correct Architectural Pattern rather than just patching the header:

  • The BFF Pattern (Backend-for-Frontend): Instead of the Blazor app acting as a generic client, it acts as a BFF. The Blazor Server app manages the session/cookies for the browser and handles the complex token exchanges with the downstream API securely on the backend.
  • Token Exchange: If the API must remain decoupled, the Senior Engineer will have the API return a JWT in a JSON body. The Blazor Server app then stores this token in its own Server-Side Session or a Secure Cookie that it manages itself, rather than trying to pass through the API’s cookie.
  • Hybrid Approach: Use a standard HTTP POST (not a SignalR call) for the login phase to ensure the browser is part of the initial HTTP request/response cycle, allowing for proper cookie setting.

Why Juniors Miss It

  • The “Magic” Fallacy: Juniors often expect frameworks to “just work” like a browser, assuming that HttpClient carries the same semantic meaning as a user typing a URL into Chrome.
  • Ignoring the Network Layer: They focus on the Application Layer (the logic of LoginAsync) and forget the Transport/Session Layer (how headers move between physical machines).
  • Misunderstanding Blazor’s Nature: They treat Blazor Server as if it were a client-side framework, failing to realize that the code is actually running in a data center, miles away from the user’s browser.

Leave a Comment