Does the refresh cookie survive the trip?

Throwaway. The facade's refresh cookie (HttpOnly; Secure; SameSite=Strict; Path), over the three hops the back office could use. Page: . Upstream: asking /api/local/config...

A. Static Web Apps alone: the Function sets the cookie itself

If this group fails, Static Web Apps is what eats the cookie, whatever the VM does.

CheckExpectedActual

B. Through the relay: SWA, managed Function, Application Gateway, VM

The candidate. The cookie is set by ASP.NET Core on the VM and relayed by /api/*.

CheckExpectedActual

C. Straight from the browser to the VM, across origins (option C)

No relay: CORS with credentials, same site under blokko.ai.

CheckExpectedActual

Manual check, Safari only (Mac, or iPhone with Web Inspector). After Run all, press . It sets blokko.spike (group B) and blokko.spike.direct (group C) again and leaves them in place. Open each link that appears below and, in that tab, read the cookie's Expires under Develop, Web Inspector, Storage, Cookies. Web Inspector only lists a cookie for a page inside its Path, which is why the links point there.

Thirty days is right. Seven days on blokko.spike.direct means Safari caps every cookie from the API host: its IP sits in a different /16 (IPv4) or /64 (IPv6) than the page's, or its name resolves through a CNAME outside blokko.ai. Every sign-in and every refresh writes a fresh cookie, so under option C the effect is being signed out after seven days without using the back office, not every week. Write down, next to both Expires, the IPs both names resolve to (nslookup cookie-test.blokko.ai, nslookup cookie-test-api.blokko.ai).