Introduction

Flutter targets web and mobile, but web authentication has different constraints than mobile development. Browsers enforce cookies, SameSite, CORS, and HttpOnly flags that change where you can safely store credentials. This article compares cookie-based sessions and token-based authentication for Flutter web, shows practical patterns for each, and explains CORS and credential propagation so your Flutter app authenticates reliably.

Cookie Setup And HttpOnly

Cookies are the simplest for protecting session state on the web because the browser sends them automatically. For security, set cookies from the server with these attributes: HttpOnly (prevents JS access), Secure (HTTPS only), SameSite=Lax or Strict (to reduce CSRF), and an appropriate Path and Domain.

Key points:

• HttpOnly cookies cannot be read by Flutter/Dart code on web. They are still sent automatically with requests if the browser accepts them.

• Server must issue Set-Cookie and return Access-Control-Allow-Credentials: true and an explicit Access-Control-Allow-Origin (not '*') for cross-origin setups.

• To defend against CSRF you can rely on SameSite=Lax for most flows or implement a separate CSRF token stored in a non-HttpOnly cookie or in the page markup and sent as a header.

When using cookies, your Flutter web client does not store tokens; instead it ensures requests include credentials (see CORS section).

Token Storage And Renewal

Token-based approaches (JWT or opaque access tokens) are popular in mobile development because apps control storage. On the web, storing tokens in localStorage or sessionStorage exposes them to XSS. Best practices:

• Avoid localStorage for long-lived tokens. If you must persist, prefer short-lived access tokens with refresh tokens that are HttpOnly cookies.

• Keep access tokens in memory in your Flutter app and refresh them via a secure refresh endpoint that uses an HttpOnly refresh cookie.

• Implement silent refresh: when the access token is close to expiry, call the refresh endpoint (server reads the HttpOnly cookie and issues a new access token) and update in-memory token.

Example: In-memory token holder and attaching Authorization header (mobile and web where token is available):

// Simple request helper that adds Authorization when token present
Map<String, String> authHeaders(String? token) => {
  if (token != null) 'Authorization': 'Bearer $token',
  'Content-Type': 'application/json',
};

Keep token handling synchronous and centralized (a provider or interceptor) to avoid race conditions during refresh.

Handling CORS For Flutter Web

CORS configuration is set on the server and is crucial for Flutter web to send cookies/credentials. Requirements:

• Access-Control-Allow-Origin: must be the specific origin of your Flutter web app (e.g., https://app.example.com).

• Access-Control-Allow-Credentials: true to allow cookies to be sent/received.

• Access-Control-Allow-Headers: include custom headers you send (e.g., X-CSRF-Token, Authorization).

• Ensure Preflight responses (OPTIONS) return appropriate headers quickly.

On the client, instruct the browser to include credentials. In Flutter web you can use dart:html HttpRequest for cross-origin cookie flows because it exposes withCredentials.

import 'dart:html' as html;

final response = await html.HttpRequest.request(
  'https://api.example.com/refresh',
  method: 'POST',
  withCredentials: true,
);

If you use the http package, inject a BrowserClient that supports credentials or use fetch via JS interop. Remember: with credentials, the server must not use a wildcard origin.

Authenticating Requests In Flutter Web

Choose a pattern based on threat model and integration complexity:

• Cookie-First: Server issues HttpOnly session or refresh cookie; client uses fetch/HttpRequest with credentials. Server sets access token in response body if needed. Good for most web flows; simpler CSRF handling and no JS-exposed tokens.

• Token-First with HttpOnly Refresh: Access token in memory; refresh token as HttpOnly cookie. Best hybrid for SPAs that also need Authorization headers.

• Pure Token (not recommended for sensitive apps): store tokens in storage, useful for simple apps but vulnerable to XSS.

Implement a centralized request layer that:

• For cookie flows calls endpoints with withCredentials: true.

• For token flows attaches Authorization headers and handles 401 by attempting a refresh.

• Treat refresh endpoints as safe operations requiring credentials on the server.

Remember to test both same-origin and cross-origin deployments and verify cookies in the browser DevTools network tab.

Vibe Studio

Vibe Studio, powered by Steve’s advanced AI agents, is a revolutionary no-code, conversational platform that empowers users to quickly and efficiently create full-stack Flutter applications integrated seamlessly with Firebase backend services. Ideal for solo founders, startups, and agile engineering teams, Vibe Studio allows users to visually manage and deploy Flutter apps, greatly accelerating the development process. The intuitive conversational interface simplifies complex development tasks, making app creation accessible even for non-coders.

Conclusion

For Flutter web, cookies (HttpOnly + Secure + SameSite) paired with server CORS configuration provide the most resilient pattern for session management while minimizing XSS exposure. Token-based models work well when you keep access tokens in memory and use HttpOnly refresh cookies to renew them. Always configure Access-Control-Allow-Credentials and a specific Access-Control-Allow-Origin on the server, and centralize request, refresh, and error handling in your Flutter code to avoid race conditions and leaks. These patterns let you reuse mobile development concepts while respecting browser security constraints on the web.