feat(auth): OAuth device grant backend + consent page (AI-050a)

[mrviduus]

AI-050a — OAuth 2.0 Device Authorization Grant (RFC 8628), backend + consent page (Phase 8)

So the headless MCP CLI (Claude Desktop spawns it over stdio — no browser) can obtain a per-user TextStack JWT, replacing the AI-048a interim static shared-token. This is the backend + web consent gate; the CLI-side DeviceFlowTokenProvider + token cache is AI-050b.

Flow

1. CLI → POST /auth/device/code → { device_code, user_code, verification_uri, verification_uri_complete, expires_in:600, interval:5 }.
2. CLI tells the user (on stderr) to visit /device and enter the user_code; meanwhile polls POST /auth/device/token (RFC 8628 errors authorization_pending / expired_token / access_denied).
3. The logged-in user approves on the consent page → POST /auth/device/approve (authed) binds the device flow to their identity.
4. The next poll returns a normal TextStack JWT (access + refresh, same shape as /auth/login).

Backend

• DeviceAuthorization entity + migration (verified on Postgres): device_code stored hashed (SHA256-hex, unique index) — never plaintext; short user_code (Crockford base32, no ambiguous chars); nullable UserId until approval; status/expiry; FK OnDelete(SetNull).
• 3 endpoints under /auth/device (+ optional deny). Token issuance reuses the exact GenerateAccessToken + CreateRefreshTokenAsync as login — full per-user JWT, single-use, 10-min TTL. Rate-limited (code 5/min, token 12/min, approve 10/min per IP). TimeProvider injected for testable expiry.
• Public base from App:BaseUrl (same key as transactional email).

Consent page /device (the only human gate)

Mounted outside the /:lang routes. Logged-in user enters/confirms the user_code (prefilled from verification_uri_complete), sees their identity + scope + an explicit "only approve if YOU started this from your own MCP client" anti-phishing warning, then Approve/Deny.

Security (adversarial review — 0 P1)

• device_code only ever stored hashed, never logged (grepped the whole flow); lookup hashes the incoming code.
• Redeem only ever mints for the consenting approver — no path to a token for a different user; no admin/extra claims.
• approve requires an authed session (401 anonymous); code/token are correctly public (the CLI has no session yet) and leak nothing pre-approval.
• Unknown device_code → expired_token (no "not found" enumeration oracle). Single-use + lazy-expiry enforced on approve and redeem.
• QA P2 fixes: approve/deny scoped to the live pending row (the filtered user_code index lets codes recur across history — stale terminal rows are now invisible, preventing a fresh flow from mis-resolving to an old row); the Deny button now actually calls /auth/device/deny.
• Residual (documented, accepted for a single-user power tool): the CLI gets a full-scope user JWT (no mcp audience claim yet); classic device-flow phishing is mitigated by the consent wording + short TTL.

Tests — 526 unit (20 hermetic DeviceCodes helper tests: normalize round-trips, hashing distinctness, no-regroup-miss) + DB-gated integration (RFC fields, pending/approved/expired, auth-required-approve, hashed storage, single-use, fresh-vs-stale-row scoping).

Verify

• dotnet test tests/TextStack.UnitTests → 526 pass · dotnet build / dotnet format --verify-no-changes → clean
• pnpm -C apps/web exec tsc --noEmit + build → clean

🤖 Generated with Claude Code