DEV Community

Cover image for System Design: SSO Authentication Using Shared Cookie for Multiple Apps
forceki
forceki

Posted on

System Design: SSO Authentication Using Shared Cookie for Multiple Apps

#architecture #backend #security #systemdesign

Building a great product often means scaling your internal tooling. But as a company grows, a common architectural headache emerges: every single internal application from the Cashier dashboard to the Point of Sale (POS) system ends up with its own isolated login system.

Before you know it, managing user credentials, sessions, and multi-app permissions becomes an absolute nightmare for both users and the security team.

A few years ago, I tackled a project to solve exactly this by centralizing authentication across multiple internal applications. The goal was to transition the entire ecosystem into a single, unified system using a central SSO Engine & IAM Service to handle complex, multi-app roles and permissions.

Note: I'm sharing this architectural breakdown and diagram because I've already received explicit permission to do so! 😉

Architectural Flow Diagram

Below is the complete sequence flow mapping out how the authentication state behaves across different subdomains.

System Design: Shared Cookie Authentication Flow

Figure 1: High-level overview of the request routing between Domain 1 (Cashier), Domain 2 (POS), and the central Identity Provider.

How the Data Flows

When mapping out this architecture, we compared two main approaches: Full Token Callback Flow (OAuth2/OIDC style) and Shared Wildcard Cookies. Because we were operating in a controlled, purely internal ecosystem sharing the exact same root domain (*.domain.com), we opted for the Wildcard Cookie route.

Here is exactly how it works under the hood:

1. The Initial Authentication (Domain 1: Cashier)

When a user first lands on cashier.domain.com:

  1. The Frontend (FE) browser checks for existing cookie validity.
  2. If no valid authentication exists, the frontend triggers a redirect to the SSO Login Page.
  3. The user inputs their credentials. The login page hands this over to the Cashier Backend API.
  4. The Backend API acts as a client, requesting authentication from the central SSO Engine & IAM Service.
  5. Once verified, the SSO Engine returns all user permissions, metadata, and the session token.
  6. The Magic Step: The Cashier Backend API issues a Set-Cookie header to the browser. Instead of scoping it strictly to cashier.domain.com, it sets the cookie domain attribute to the wildcard root: .domain.com.

2. Seamless Cross-Domain Access (Domain 2: POS)

Now, when the same user navigates to pos.domain.com:

  1. Because the cookie was set at the root .domain.com level, the browser automatically includes the cookie in requests heading to the POS Frontend and Backend API.
  2. The POS Backend API captures this incoming cookie.
  3. To ensure strict validation, integrity, and up-to-date permissions, the Backend API securely forwards the cookie along with an app_key and secret_key directly to the central SSO Engine & IAM Service.
  4. The SSO engine verifies the keys and the cookie, returning the specific permissions and tokens required for the POS domain.
  5. The session is seamlessly established without a single redirect or manual login prompt.

Why Wildcard Cookies? (Pros & Cons)

While a Full Token Callback Flow (using authorization codes and state parameters) is the gold standard for public-facing third-party apps, it introduces significant engineering overhead, constant browser redirects, and callback route handling for every internal app you build.

For our specific use case, Shared Wildcard Cookies offered distinct advantages:

The Pros:

  • Zero Redirect Fatigue: Users transition between cashier. and pos. instantly. No jarring page blinks or auth redirects.
  • Radical Simplicity: Frontend applications don't need complex token-storage mechanisms (like dealing with localStorage vs sessionStorage XSS trade-offs). They simply let the browser do what it does best: manage cookies.
  • Centralized Cryptographic Trust: By enforcing that every backend API must validate the cookie alongside an app_key and secret_key against the central SSO engine, we eliminated the risk of downstream microservices blindly trusting stale data.

The Trade-offs to Keep in Mind:

  • Tight Domain Coupling: This strategy strictly requires your apps to live under the same top-level domain. If your app moves to completely-different-domain.com, this mechanism breaks, and you'll have to implement standard token exchange.
  • CSRF Mitigation is Mandatory: Because cookies are sent automatically by the browser, you must implement robust Cross-Site Request Forgery (CSRF) defenses, ensure HttpOnly and Secure flags are strictly enforced, and set proper SameSite policies (Lax or Strict depending on your cross-subdomain API interactions).

Conclusion

When building internal tooling, over-engineering can be just as dangerous as under-engineering. Choosing a Shared Wildcard Cookie flow backed by a robust, server-to-server app_key verification loop allowed us to ship a highly secure, centralized IAM ecosystem with minimal architectural friction.

Top comments (0)