Syncing Authentication State Across Subdomains

Managing authentication across multiple subdomains (such as app.example.com, api.example.com, and example.com) requires a cohesive strategy to ensure users remain logged in seamlessly without compromising application security. Web development teams primarily achieve this synchronization through wildcard domain cookies, centralized Identity Providers (IdP) using Single Sign-On (SSO) protocols, shared session stores, and client-side inter-tab communication APIs.

1. Wildcard Domain Cookies

The most common and straightforward method is scoping session cookies to the root domain. By default, a cookie set by app.example.com is only accessible to that specific subdomain. However, by setting the Domain attribute to the apex domain, all subdomains inherit access:

  • Cookie Configuration: Setting Domain=.example.com allows example.com, app.example.com, and admin.example.com to read the cookie.
  • Security Attributes: Teams must pair this configuration with Secure (ensuring transit only over HTTPS), HttpOnly (preventing access via JavaScript to mitigate XSS attacks), and an appropriate SameSite setting (Lax is standard for cross-subdomain top-level navigations).
  • Trade-offs: This approach requires all services to share the same parent domain. If a less-secure subdomain is compromised, malicious scripts could potentially capture or overwrite authentication cookies for the entire domain tree.

2. Centralized Identity Providers and SSO (OAuth 2.0 / OIDC)

When subdomains are hosted on disparate infrastructure, run by separate teams, or require strict isolation, teams rely on centralized authentication via OAuth 2.0 and OpenID Connect (OIDC).

  • Architecture: Authentication is delegated to a dedicated subdomain (e.g., auth.example.com).
  • The Flow: When an unauthenticated user visits dashboard.example.com, they are redirected to auth.example.com. The auth server checks for an active session, issues an authorization code, and redirects the user back with tokens (Access Token and ID Token).
  • Silent Authentication: Modern Single Page Applications (SPAs) use silent token renewal—performing background checks using promptless OpenID flows (prompt=none) or web workers to verify authentication state without forcing a user-facing page refresh.

3. Shared Backend Session Stores

For applications using server-side sessions rather than stateless JWTs, synchronization occurs at the database or cache layer:

  • Central Cache (Redis / Memcached): Each subdomain runs its own server instance, but all servers connect to a shared distributed cache.
  • Mechanism: The user presents an opaque session identifier (stored in a wildcard cookie). Whichever subdomain receives the request queries the shared Redis cluster to validate the session data and retrieve the user's permissions.
  • Benefits: Instant session invalidation. Revoking a session in the centralized store immediately terminates the user's access across all subdomains.

4. Client-Side Real-Time Synchronization and Global Logout

Coordinating state across active browser tabs running different subdomains—especially during logout events—is critical for security and user experience.

  • BroadcastChannel API: If subdomains embed an identical central authorization iframe, that iframe can utilize the BroadcastChannel API to notify other open tabs when an authentication state changes.
  • Storage Events: Similar to the channel API, an embedded cross-domain iframe can write a timestamp to localStorage. Other tabs listening to the storage event will detect this update and trigger a re-authentication check or force a redirect to the login page.
  • Back-Channel Logout: In federated setups, the identity provider sends direct server-to-server notifications to all registered subdomains when a user logs out, instructing each backend to destroy the corresponding local session.