A single-page client where the cookie path is the security boundary
An SPA behind a backend-for-frontend holding three separately-audienced tokens at once, isolated by cookie Path, degrading visibly when one cannot be got.
A client needing three APIs must hold three tokens with nothing in common. If any of them can be sent to the wrong proxy, the whole narrowing scheme upstream was decorative.
- Angular
- Vue 3
- TypeScript
- NestJS
- Tailwind
- Playwright
The client half of the OpenID Connect stack: an application behind a backend-for-frontend, built to decisions I made and wrote down before the code that implements them.
Three tokens, and why they cannot touch
Every session performs three token exchanges — inventory, social, notifications — plus the root token, re-run on every refresh.
Cookie Path is the isolation mechanism. Each service token lives at its
own /api/<service> path, so the browser only sends it to that proxy. A sibling
cookie at /api would be sent to every proxy and would void the entire
narrowing property the authorization server works to establish. The security
boundary is a cookie attribute — which is worth stating plainly, because it is
easy to break by accident and nothing will complain.
The exchange is tiered: inventory is required, the other two are best-effort with retry. A failed optional exchange clears its cookie rather than leaving a stale one — the fresh-root-with-stale-downstream state that everything else is built to fail closed against.