Keep Microsoft Tokens On The Server
Context
TenCtrl reads Microsoft 365 data on behalf of a signed-in technician. Access and refresh tokens for Microsoft Graph grant read access to a tenant's user directory, so where they live decides how much a browser compromise can leak.
Decision
Run Microsoft sign-in as a confidential server-side web app with MSAL Node and the authorization code flow. Tokens stay in a server-side session store; the browser receives only an opaque, HTTP-only TenCtrl session identifier. The tenant context is derived from validated token claims, never from browser input.
Alternatives Considered
Single-page app with tokens in the browser
- No server session store to run.
- Simple to prototype.
- Tokens become reachable by any script running in the page.
- Harder to keep tokens out of logs and client-side error reports.
Pass the tenant identifier from the browser
- Simple multi-tenant routing.
- A crafted request could target another tenant.
Reasoning
Keeping tokens server-side limits what a browser-side issue can expose, and deriving the tenant from the token keeps tenant isolation out of the client's hands. The current development runtime keeps sessions in process memory, which means a restart signs users out; an encrypted shared store is planned before any multi-instance deployment.