Same-origin, the login problem, and how to solve it

Why the session drops on refresh (F5) in QA (issue #553), what each term means, what breaks if you get it wrong, and the options to do it right — for the QIIUB admin portal, merchant portal, and shared API.

Created: 2026-07-06 | Last Updated: 2026-07-07

Glossary (plain English)

Origin

The identity of a web address = scheme + host + port. https://admin.qa.qiiub.com and https://api.qa.qiiub.com are different origins (different host). The browser walls off each origin from the others for security.

Same-origin

The web page and the API it talks to live under the one origin. Cookies the API sets are then readable by the page's JavaScript, and no CORS is needed.

CORS — Cross-Origin Resource Sharing

The browser's controlled exception to the origin wall: a page on origin A may call origin B only if B sends headers explicitly allowing it. It's what you need when the SPA and API are on different origins. Same-origin removes the need for it entirely.

Cookie / HttpOnly / SameSite

A small credential the browser stores and re-sends. HttpOnly = JavaScript can't read it (protects the refresh token). SameSite=Strict = only sent on same-site navigations. A cookie is bound to the host that set it — JS on another host can't read it.

CSP — Content-Security-Policy

An HTTP response header that tells the browser which sources a page may load scripts/styles/connections/frames from. It's the main defense against XSS (an attacker injecting a script). QIIUB emits an enumerated allowlist for the SPA hosts (P4).

HSTS — HTTP Strict-Transport-Security

A response header that tells the browser "always use HTTPS for this site, never plain HTTP." Prevents downgrade / man-in-the-middle. QIIUB emits it outside Development (P3).

Reverse proxy

A server that sits in front and forwards requests to a backend, so the browser only ever sees one address. Nginx, YARP, CloudFront, Cloudflare, and Azure Front Door can all act as one.

BFF — Backend-for-Frontend

The pattern of giving each frontend a same-origin backend that holds the tokens/cookies and proxies to the real services. The recognized secure pattern for SPA auth. Coined at SoundCloud (2015); used by Netflix, Spotify; documented by Microsoft, Auth0, Duende.

Azure Front Door

Microsoft's global edge service: reverse proxy + CDN (caches content near users) + Web Application Firewall (WAF) + DDoS protection + global routing/TLS. Primary uses: put a fast, protected front on your app worldwide. It can also serve as the same-origin reverse proxy. Paid, recurring.

WAF / DDoS

A WAF (Web Application Firewall) filters malicious requests (injection, bots). DDoS = distributed denial-of-service, a flood of traffic meant to knock you offline; mitigated at the edge (Cloudflare / Front Door), not in the app.

CDN

Content Delivery Network — caches your static files on servers near users for speed. Azure Static Web Apps and Cloudflare/Front Door are CDNs.

The problem

The browser treats each origin as a sealed room. A cookie the API drops lives in the API's room; the portal's JavaScript, running in a different room, cannot read it.

What breaks if you get it wrong

• Cross-origin (today): user logs in, but any refresh — F5, a new tab, or the silent 13-min refresh — fails because the CSRF cookie is unreadable → user is bounced to /login. Looks like "it keeps logging me out." (This is #553.)
• Cookie without Secure/wrong SameSite: either the browser refuses to store it, or it leaks across sites. Auth silently breaks or becomes insecure.
• Prefix rewrite in the proxy: if a proxy rewrites /api to something else, the refresh cookie's Path=/api/auth no longer matches → cookie never sent → logout. (Why the /api path must be forwarded verbatim.)
• No CSP: an injected script can run and steal data. No HSTS: a downgrade/MITM can intercept. Both are one-line headers we now emit.
• CORS left wide open (*) as a lazy "fix" for the cross-origin pain: turns the API into an open target. The right fix is same-origin, not permissive CORS.

The options to do it right

All of these achieve same-origin. They differ in cost, deploy independence, and extra moving parts. (A/B/C are the mechanisms evaluated in the QA spike; the edge-proxy row and Front Door are the broader alternatives.)

Decision & environments (current thinking)

Two decisions at two scopes — they coexist:

• Strategic edge (Mike, 2026-05-22): the platform edge/WAF is Azure Front Door + Azure DNS — an all-Azure pane for the PCI / enclave / multi-region future. This is the prod answer.
• QA (now): no Front Door. QA is lean/disposable — the same-origin login is solved for $0 by serving the SPAs from the App Service (Plan C, already merged). Local dev is same-origin via the Vite proxy. Front Door would bill ~$35/mo even while parked, with nothing in QA that needs it.

Is this industry-standard? Yes.

• BFF pattern — coined at SoundCloud (2015); used by Netflix, Spotify; a documented Azure Architecture Center pattern; the Auth0/Duende/FusionAuth recommendation for SPA auth with HttpOnly cookies.
• Same-origin via server/proxy — recommended by AWS (CloudFront same-domain) and Microsoft (serve SPA from ASP.NET Core; Front Door as SPA proxy) to eliminate CORS and keep cookies first-party.
• Serving the SPA from the API app (Plan C) is Microsoft's official ASP.NET Core production pattern (static files + MapFallbackToFile).
• Salesforce uses My Domain (custom domains) so the UI and session share a host — same principle.

Why our existing MVC apps (WIDS365) don't hit this

It's not "API vs no API." WIDS365's portals also use an API to reach the DB (wids365-api, called via a server-side AuthHttpClient). Both QIIUB and WIDS365 have an API. The difference is who calls the API and where the session lives:

WIDS365 concretely (verified in code): the boarding/central app (wids365-central-mvc — has TenantController, Register/SignUp views) and the operational portal (wids365-mvc) are each their own MVC app with its own AuthController + cookie authentication (AddCookie / SignInAsync). Each holds the session server-side on its own origin and calls wids365-api server-to-server. The browser never talks to the API directly, so there's no JS-readable-cookie-across-origins issue.

The SameSite / third-party-cookie future

Browsers have been tightening cross-site cookies for years (SameSite defaults, the third-party-cookie saga). What breaks is cross-site usage — a cookie shared between different sites (e.g. Salesforce embedding Lightning inside a third-party page).

Detect early: a CI synthetic test (login → F5 → still signed in) across Chrome/Firefox/WebKit; cookie warnings in the browser console; a Sentry alert if auth-refresh 401s spike; cookie-attribute checks in the QA DAST. Fix if it ever bites: stay same-origin; keep __Secure- + correct SameSite; and for any genuine cross-site need use SameSite=None; Secure; Partitioned (CHIPS).

DDoS / WAF — a separate layer (the decided edge = Azure Front Door)

Same-origin (Plan C) fixes the login/cookie problem. It gives you nothing against DDoS — that is a different concern, handled at the edge, not in the app.

• Baseline: Azure already provides infrastructure-level DDoS protection on public IPs for free.
• App-layer (L7) DDoS + WAF — the decided answer is Azure Front Door. Mike's subscription-conventions decision (2026-05-22) is Azure Front Door Standard ($35/mo) for MVP → Premium ($330/mo) for PCI / multi-region / Private Link, with Azure DNS for qiiub.com (not Cloudflare) — a single all-Azure pane for the enclave/PCI/multi-region future. Front Door in front of the App Service delivers same-origin and CDN + WAF + DDoS in one Azure-native layer.
• Front Door billing (important): ~$35/mo base fee, billed hourly, charged even with zero traffic. It cannot be paused/disabled — disabling endpoints stops data/request charges but the base fee runs until you delete the profile. So an idle Front Door in a disposable/parked env keeps billing — a reason not to leave one standing in QA.
• "Plan C makes Front Door optional" (for the login fix) means: you don't need Front Door just to get same-origin — Plan C already does that for $0. Front Door is added for the edge concerns (WAF/DDoS/CDN/global), which is a prod need, not a QA one.

Scale, CDN & production sizing

A CDN (Content Delivery Network) keeps copies of your static files (the SPA's JS/CSS/images) on servers — "edge POPs" — near the user, all over the world. The browser fetches the app from the closest POP, not from your one compute server in one region. That means low latency globally, near-infinite scale for static bytes, and it's cheap.

So Plan C's cost, restated: you give up the "static assets served from a global CDN edge" that the SWA gave you for free. Concretely — higher first-load latency for distant users, static-file serving consuming your API compute, and static + API scaling as one unit (autoscale is coupled).

Production sizing (not QA)

QA runs on App Service Plan B1 (Basic) on purpose — lean/disposable, single instance, no autoscale, no deployment slots. Fine for demos, not for ~1,000 merchants.

• Prod would be Standard (S1+) or, more likely, Premium v3 with autoscale (multiple instances by load) and deployment slots (deploy to a staging slot → warm → swap → zero-downtime + instant rollback — which removes the "a deploy restarts everything" concern under Plan C).
• Exact SKU/instance count is a capacity/load-test decision on real traffic — note the POS is offline-first, so API load is more sync-bursts + portal/admin usage than transaction-per-request, which can lower the requirement.
• The decision interaction: at prod scale, slots make Plan C's downtime concern go away, but the CDN-edge point above argues for keeping static on an edge. Decide Plan-C-vs-edge with three lenses on the table — cookies (#553), deploy independence + slots, and CDN-at-the-edge — not just the cookie one.

Native clients — mobile app and the POS

Native clients are not bound by the browser's origin/cookie rules. They hold their token in secure device storage and send it in the Authorization: Bearer header — no cookies, no same-origin requirement. So the same-origin change for the web portals doesn't affect them. But the two native clients relate to the API differently:

• Mobile app (networked): a normal online client. It calls the shared API cross-origin via CORS + Bearer tokens. Recommendation: one shared API, not a separate one — the same API serves the browser (same-origin) and native (CORS) at once. Details decided when mobile lands; nothing here blocks it.
• POS (Tauri, offline-first): it works locally against its own local store. Its primary channel to the platform is the sync connector (bidirectional reconcile) — not general request-per-action API calls. Some operations (e.g. Returns) may end up as direct calls or go through an intermediary — TBD. Either way it isn't governed by browser same-origin, and CORS (or the sync channel) covers it.