Authentication-config failure leaves the frontend in an authorization dead end

[romanlutz]

Describe the bug

If /api/auth/config fails while protected APIs return 401, the frontend treats authentication as disabled and renders the normal Home and Configuration surfaces with raw Missing or invalid Authorization header text. No login control, explicit authentication-initialization error, or viable recovery path appears.

fetchAuthConfig() converts non-2xx responses and network failures into an empty auth configuration, which AuthProvider interprets as authentication being disabled. This produces a mixed normal-shell/unauthorized state. See msalConfig.ts lines 26-37.

Steps/Code to Reproduce

1. Make the authentication configuration request return 503.
2. Make protected API requests return 401.

GET /api/auth/config
HTTP/1.1 503 Service Unavailable

GET /api/targets?limit=200
HTTP/1.1 401 Unauthorized

{"detail":"Missing or invalid Authorization header"}

3. Open Home and Configuration.
4. Observe repeated failed requests, raw authorization text, and no Login action.
5. Choose Configuration's Refresh action and observe that it retries target data but cannot recover authentication.

Expected Results

The app presents an explicit authentication-initialization failure with a retry action and/or the configured login path. It should distinguish a failed auth-config request from an intentional auth-disabled configuration.

Actual Results

The normal application shell renders in an unauthorized state:

Home: Missing or invalid Authorization header
Configuration: Error: Missing or invalid Authorization header
Login controls: 0
Authentication-state errors: 0

The generic Configuration refresh cannot repair the authentication state.

Screenshots

N/A. The exact visible output and response sequence are included above.

Versions

• OS: Windows
• Browser: Playwright Chromium (@playwright/test 1.62.1)
• Python: 3.14.4
• PyRIT: main at 37bb7377ec3f8ed547b9a52f4536447c097e0f33

[feiiiiii5]

I'd like to take this one. I've reproduced the shape locally: fetchAuthConfig() collapses both non-2xx responses and network failures into an empty AuthConfig, which AuthProvider reads as "auth disabled" — so the app renders the normal shell while protected APIs return raw 401 text, with no login control or error surface.

Plan: make the two failure paths in fetchAuthConfig throw instead of returning an empty config (the existing AuthProvider catch already renders a proper Authentication Error page), keep a 200-with-empty-config response meaning auth-disabled, and add regression tests for both branches. Will open a PR shortly.