andrewjroberts

# MSAL + React Router Route Modules Auth Architecture

## 1. Decision

Use **`@azure/msal-browser` as the actual auth engine** and wrap it in a small app-owned auth facade/store.

Do **not** make `@azure/msal-react` the center of the architecture. It is useful for component-only convenience APIs, but your app needs both React hooks and point-in-time `.getState()` semantics from `clientLoader`s, which are outside React component context. MSAL React is built on React context, requires `MsalProvider`, and exposes hooks/templates to components under that provider. ([Microsoft Learn][1])

Recommended shape:

andrewjroberts

No — I **would** do that. That’s cleaner than stuffing everything under `ui-config.auth.microsoftIdentity`.

I’d shape it like this:

```ts
export type UiConfig = {
  app: {
    uiVersion: string;
    serviceVersion: string;
    environment: "local" | "dev" | "qa" | "prod";

andrewjroberts

# Auth Store Documentation

This store owns the browser-side MSAL lifecycle for the app. It keeps MSAL behind a small Zustand API, coordinates redirect login flows, exposes typed auth actions, and persists only the redirect metadata needed to survive MSAL redirect navigation.

The intended public API is:

```ts
const auth = useAuthStoreActions();

await auth.start();