System Design: SSO Authentication Using Shared Wildcard Cookies for Multiple Internal Apps

The Problem: Fragmented Logins Across a Growing Internal Suite

When a company expands its internal tooling—cashier dashboards, point‑of‑sale terminals, inventory managers, reporting consoles—each team often builds its own authentication layer. The result is a patchwork of login pages, session stores, and permission databases. Users end up juggling passwords, and security teams struggle to enforce consistent policies. The pain points are easy to spot:

• Credential sprawl – every app stores its own hash, increasing breach surface.
• Session inconsistency – a user logged into one tool is forced to re‑authenticate for the next.
• Permission drift – role changes in one system may not propagate to others.

The goal was to replace this chaos with a single source of truth for identity and access, while keeping the developer experience lightweight.

---

Solution Overview: Central SSO Engine + Wildcard Cookie

We evaluated two classic patterns for cross‑application authentication:

1. Full OAuth2/OIDC token‑callback flow – the "gold standard" for public‑facing apps, involving redirects, authorization codes, and token exchanges.
2. Shared Wildcard Cookie – a browser‑native session that lives at the root domain (e.g., .company.com).

Because every internal service already shared the same DNS suffix (*.company.com), we chose the second option. The architecture consists of three logical pieces:

• Identity Provider (IdP) – a central SSO engine that authenticates users, issues a signed session cookie, and stores role/permission data.
• Frontend Apps – thin JavaScript bundles that rely on the browser to send the cookie automatically.
• Backend APIs – each service validates the cookie against the IdP, using an app_key/secret_key pair to prove its identity.

The flow is illustrated in the diagram below (Figure 1). The key invariant is that no frontend ever stores a token; the browser’s cookie handling does the heavy lifting.

---

Step‑by‑Step Flow

1️⃣ Initial Login on cashier.company.com

1. The user navigates to cashier.company.com. The frontend checks for a cookie named SESSION_ID scoped to .company.com.
2. No cookie → the frontend redirects the user to the IdP login page (login.company.com).
3. After successful credential entry, the IdP creates a signed JWT payload containing user ID, roles, and an expiration timestamp.
4. The IdP responds with a Set‑Cookie header: Set‑Cookie: SESSION_ID=<signed‑jwt>; Domain=.company.com; Path=/; HttpOnly; Secure; SameSite=Lax.
5. The browser stores the cookie and automatically includes it on every subsequent request to any subdomain.

2️⃣ Transparent Access on pos.company.com

1. The user clicks a link to pos.company.com. The browser sends the SESSION_ID cookie with the request.
2. The POS backend receives the cookie and forwards it, together with its own app_key/secret_key, to the IdP via a server‑to‑server call (POST /introspect).
3. The IdP validates the JWT signature, checks the app_key/secret_key pair, and returns a permission envelope specific to the POS domain (e.g., canCreateOrder, canRefund).
4. The POS service creates a short‑lived request‑scoped token for downstream microservices, but the user never sees another login screen.

Because the cookie is already present, the user experiences a single sign‑on across all internal tools with zero redirects after the first login.

---

Why Wildcard Cookies Made Sense Here

Advantage	Explanation
Zero redirect fatigue	Users move between subdomains instantly; the browser does the work.
Simplified front‑end code	No need to store tokens in localStorage or manage refresh cycles; the cookie is automatically sent.
Central cryptographic trust	Every backend validates the cookie against the IdP, preventing stale or forged sessions.
Performance	One round‑trip to the IdP per request (or per batch) is cheaper than a full OAuth exchange with multiple redirects.

---

Trade‑offs and Mitigations

Trade‑off	Mitigation
Tight domain coupling – Works only when all apps share a common parent domain.	For any future SaaS‑style product that lives on a different domain, fall back to standard OAuth2/OIDC flows.
CSRF exposure – Cookies are sent automatically, so a malicious site could trigger unwanted actions.	Enforce SameSite=Lax (or Strict if no cross‑subdomain POSTs are needed), use double‑submit CSRF tokens for state‑changing endpoints, and keep the cookie HttpOnly and Secure.
Cookie size limits – Large JWT payloads can exceed the ~4KB limit.	Store only a user identifier in the cookie; fetch full permission sets from the IdP on each request.
Revocation latency – Revoking a session requires either short cookie lifetimes or a revocation list checked by the IdP.	Use a short maxAge (e.g., 15 min) with a refresh endpoint that re‑issues the cookie after validating the session in the IdP database.

---

Implementation Tips for Engineers

1. Sign the cookie with a strong algorithm – HMAC‑SHA256 or RSA‑PSS, and rotate keys regularly.
2. Never expose the raw JWT to the client – keep it HttpOnly so JavaScript cannot read it.
3. Version the cookie schema – include a ver claim to allow future format changes without breaking old services.
4. Audit app_key/secret_key usage – store them in a secret manager (e.g., AWS Secrets Manager) and rotate them on a schedule.
5. Log introspection failures – a sudden spike may indicate a token‑theft attempt or a mis‑configured service.

---

When to Prefer a Full OAuth2/OIDC Flow

If any of the following apply, the wildcard‑cookie approach becomes fragile:

• External partners need access from a completely different domain.
• You must support mobile apps that cannot share browser cookies.
• Public‑facing services require third‑party login (Google, Azure AD, etc.).

In those cases, implement the standard Authorization Code Grant with PKCE, store tokens securely on the client, and use refresh tokens for long‑lived sessions.

---

Closing Thoughts

Internal tooling often suffers from over‑engineered security solutions that add latency and complexity without delivering real value. By anchoring authentication to a single, signed wildcard cookie and coupling each backend to the IdP via a lightweight app‑key verification step, we achieved:

• Consistent user experience across dozens of apps.
• Centralized permission management.
• Minimal front‑end code churn.

The trade‑offs are clear—domain coupling and rigorous CSRF defenses are non‑negotiable—but for a closed, same‑root‑domain ecosystem the payoff is a dramatically simpler, faster, and more maintainable authentication layer.

---

Further reading

• OAuth 2.0 Authorization Framework (RFC 6749)
• OWASP CSRF Prevention Cheat Sheet
• JSON Web Token (JWT) Best Practices