Mid-session authorization (auth challenges), including step-up auth support (SEP-2350)

[BobDickinson]

Summary

Inspector does not handle authorization failures that occur after a successful MCP connect, including things like expired or revoked tokens, and runtime insufficient-scope errors.

Problem

Connect-time OAuth and EMA are implemented today. Once connected:

• Access tokens can expire or be revoked mid-session.
• Tool calls can return 403 insufficient_scope and require elevated scopes (SEP-2350 step-up).
• On web, the MCP server is remoted with a frozen token snapshot at connect time. The backend cannot complete interactive OAuth; mid-session failures are not surfaced or recovered.

TUI has partial behavior (EMA legs 2–3 can re-mint with a live provider) but no unified mid-session path. CLI is largely unwired.

What needs to happen

Introduce a normalized AuthChallenge model and a single handleAuthChallenge() entry point that:

• Detects 401/403 auth failures on MCP traffic (not just at connect).
• Attempts silent recovery where possible (refresh, EMA legs 2–3 re-mint).
• Falls through to interactive auth when needed (redirect, step-up consent).
• On web: backend emits challenges over SSE; browser handles auth and reconnects to re-snapshot tokens.
• On TUI/CLI: same handler on the live transport, before relying on SDK retry alone.
• Retries the failed MCP request after successful recovery.

EMA step-up with a valid IdP session should re-mint legs 2–3 silently (no resource-AS redirect). Standard OAuth step-up needs interactive consent with SEP-2350 scope union.