Add device flow verification page and DCR support

[reyortiz3]

Summary

Follow-up to #6647 (RFC 8628 Device Authorization Grant), which added storage,
the /oauth/device_authorization endpoint, and the token-endpoint grant
handler but explicitly left two gaps open, both called out in that PR's
description as required before DeviceFlowEnabled is safe to turn on for
real traffic:

1. No verification page. POST /oauth/device_authorization mints a
   device_code/user_code pair whose verification_uri points at
   GET /oauth/device — but that route didn't exist.
   storage.MarkDeviceRequestAuthorized/MarkDeviceRequestDenied were only
   ever called by the integration test, directly against storage.
2. No way to register a device-flow client. DCR's grant-type allowlist
   only permitted authorization_code/refresh_token.

This PR closes both gaps, so the device flow is now usable end to end by a
real client and a real human.

What changed:

• Storage — PendingDeviceLoginStorage / PendingDeviceConfirmationStorage
  (memory + Redis), modeled on the existing PendingAuthorizationStorage.
  The confirmation record is addressed only by an opaque, unguessable token
  handed to the browser as a hidden form field — the resolved identity is
  never round-tripped through the browser as editable form data.
• DCR — a device_code-only carve-out (parallel to the existing
  private_key_jwt one): redirect_uris/response_types are not required
  for a registration whose grant types are exactly {device_code} or
  {device_code, refresh_token}.
• Verification page — GET/POST /oauth/device (enter/confirm the
  user_code, redirect to the first configured upstream IDP) and
  POST /oauth/device/confirm (explicit Approve/Deny), rendered via
  html/template — the first HTML surface in pkg/authserver (every other
  handler writes JSON). The three pages (verify, confirm, result) use a
  ToolHive/Stacklok-branded palette with light/dark support via
  prefers-color-scheme, no external font/CDN dependency (air-gapped/
  enterprise deployments).
• /oauth/callback is now shared between the OAuth-client
  authorization_code flow and the device flow's login. An upstream IDP's
  redirect_uri is fixed per upstream at construction
  (upstream.OAuth2Config.RedirectURI / AuthCodeURL), so there is no way to
  register a second callback path for the verification page's login — see
  "Special notes" below.
• Hardening from review: the deny action now surfaces a storage failure
  instead of always reporting success; the shared /oauth/callback dispatch
  and the verification page's user_code re-checks distinguish a genuine
  storage error (500) from an expired/not-found request (400) instead of
  collapsing both into the same client error; POST /oauth/device is now
  rate-limited like /oauth/device_authorization; the rendered pages send
  anti-framing/no-sniff headers.
• Integration test — TestIntegration_DeviceFlow_FullHappyPath now
  drives the real HTTP flow through a mock upstream IDP (mockoidc) instead of
  simulating the verification page by calling storage directly.

Related: stacklok/stacklok-enterprise-platform#4127 (tracked in #6647).

Type of change

• New feature

Test plan

• Unit tests (task test)

• Linting (task lint-fix)

• pkg/authserver/storage: store/load/delete/expiry for both new storage
  types, in both memory_test.go and redis_test.go.

• pkg/authserver/server/registration: device_code-only registration
  succeeds without redirect_uris/response_types; device_code +
  refresh_token succeeds; device_code with response_types set is rejected;
  device_code mixed with authorization_code still requires redirect_uris
  (the carve-out only applies to an exact device-code-only grant set).
  Updated two pre-existing CIMD tests whose fixtures relied on device_code
  being an unsupported (filtered-out) grant type — it's now supported.

• pkg/authserver/server/handlers: full happy path (submit code → redirect →
  callback → confirm page → approve), deny path (including a storage failure
  on deny, and deny-then-replay of the confirm token), invalid/expired
  user_code, unknown callback state, unknown/reused confirm token
  (single-use, including a concurrent-replay race test).

• pkg/authserver/integration_test.go:
  TestIntegration_DeviceFlow_FullHappyPath rewritten to drive the real
  HTTP flow end to end through a mock OIDC upstream (submit → upstream login
  → shared callback → confirm → poll /oauth/token → success → replay
  fails).

• Manual verification: ran the embedded auth server locally (mock upstream,
  DCR-registered device-code client) and drove the full flow through a real
  browser against the new verification/confirm/result pages.

• Verified independently: full-repo go build ./... clean; go test ./pkg/authserver/... green across every package; task lint-fix clean.

Changes

File	Change
pkg/authserver/storage/types.go, memory.go, redis.go, redis_keys.go	PendingDeviceLoginStorage / PendingDeviceConfirmationStorage + both backend implementations
pkg/authserver/server/registration/dcr.go	device_code-only DCR carve-out
pkg/authserver/server/handlers/device_verification.go	New: verification-page handlers, branded HTML templates, error-handling/security hardening
pkg/authserver/server/handlers/callback.go	/oauth/callback now dispatches between the OAuth-client and device-flow logins, distinguishing storage errors from not-found
pkg/authserver/server/handlers/handler.go	Route registration + rate limiting for the verification page
pkg/authserver/integration_test.go	Device flow test now drives the real HTTP page through a mock upstream

Does this introduce a user-facing change?

Yes: with DeviceFlowEnabled on, a device-flow client can now be fully
authorized by a real human via the verification page, and a device-flow
client can be dynamically registered via DCR. Both were previously
non-functional stubs (the flag existed but nothing could actually complete
the flow).

Implementation plan

Approved implementation plan

Device Flow Verification Page + DCR Support

Context

PR #6647 (merged, 59ba54dbd) added RFC 8628 Device Authorization Grant support to the embedded OAuth
authorization server (pkg/authserver/), gated behind DeviceFlowEnabled (off by default). Code review on
that PR (jhrozek) flagged that the feature is not actually usable end-to-end yet:

1. POST /oauth/device_authorization mints a device_code/user_code pair whose verification_uri points
   at GET /oauth/device — but that route doesn't exist. storage.MarkDeviceRequestAuthorized/
   MarkDeviceRequestDenied are only ever called by the integration test, directly against storage.
2. pkg/authserver/server/registration/dcr.go's DCR grant-type allowlist only permits
   authorization_code/refresh_token, so there is also no way to register a client allowed to use the
   device_code grant.

Both gaps were called out in the same PR description update ("DeviceFlowEnabled must stay off ... until both
follow-ups above land") and are being addressed together here, in one PR, per that plan.

Part A: Device verification page

Flow

1. GET /oauth/device[?user_code=XXXX-XXXX] — DeviceVerificationHandler renders an HTML form asking
   the user to enter/confirm the user_code (pre-filled from the query param when the client sent
   verification_uri_complete).
2. POST /oauth/device — DeviceVerificationSubmitHandler normalizes the submitted code, loads the
   DeviceRequest via storage.LoadDeviceRequestByUserCode (already exists), and validates it is
   DeviceRequestStatusPending and unexpired. On success, generates upstream login secrets (reusing
   newUpstreamAuthSecrets from authorize.go), stores a PendingDeviceLogin row keyed by that state, and
   redirects (302) to h.upstreams[0].Provider.AuthorizationURL(...).
3. Upstream callback — the upstream IDP's redirect_uri is fixed per upstream at construction, so this
   reuses the existing /oauth/callback endpoint (discovered during implementation; see PR description).
   CallbackHandler resolves the identity and stores it server-side behind a fresh opaque token, then
   renders the Approve/Deny confirmation page.
4. POST /oauth/device/confirm — loads+deletes the PendingDeviceConfirmation by token (single-use),
   and calls storage.MarkDeviceRequestAuthorized (approve) or MarkDeviceRequestDenied (deny).

Only h.upstreams[0] (the first configured upstream) is used — matching AuthorizeHandler's first-leg
behavior — with no multi-upstream authorization chain support for device flow.

New storage types

PendingDeviceLoginStorage and PendingDeviceConfirmationStorage, modeled on PendingAuthorizationStorage,
implemented for both MemoryStorage and RedisStorage, embedded into Storage.

Part B: DCR support for device_code

Add oauthproto.GrantTypeDeviceCode to allowedGrantTypes; a device-code-only carve-out (parallel to the
existing private_key_jwt one) skips the redirect_uris/response_types requirements when the grant types
are exactly {device_code} or {device_code, refresh_token}.

Testing

Storage round-trip tests for both new types (memory + Redis); handler tests for the full happy path, deny,
and error paths; DCR validation test cases for device-code-only registration; integration test rewritten to
drive the real HTTP flow through a mock upstream IDP instead of simulating the verification page via direct
storage calls.

Special notes for reviewers

• Architectural correction made mid-implementation: the original plan called for a distinct
  GET /oauth/device/callback route. While implementing it, I found that upstream.OAuth2Provider's
  redirect_uri is fixed per upstream at construction time (upstream.OAuth2Config.RedirectURI, baked into
  the golang.org/x/oauth2 config used by AuthCodeURL) — there's no way to pass a different redirect_uri
  per authorization attempt. So the upstream IDP will always redirect back to whatever /oauth/callback was
  registered with it, never a second device-flow-specific path. I unified this by having CallbackHandler
  try LoadPendingAuthorization first (the existing OAuth-client flow), and fall back to
  LoadPendingDeviceLogin when the state doesn't match — see callback.go's
  loadPendingOrCompleteDeviceLogin/tryCompleteDeviceLogin. This avoids requiring operators to register a
  second redirect_uri with their upstream IdP, which many IdPs require to be pre-registered exactly.
• Consent step: the verification page shows an explicit Approve/Deny confirmation screen after upstream
  login, rather than auto-approving immediately — matches how GitHub/Google device flows behave.
• No multi-upstream chain support for the verification page — it always uses the first configured
  upstream, matching AuthorizeHandler's first-leg behavior. Chained upstream authorization for device flow
  is out of scope here.
• Page styling: the three rendered pages are cosmetic only — no change to the underlying OAuth
  semantics. Kept deliberately simple (a single card, no heavy branding chrome) to stay in the same visual
  family as the existing plain OAuth-adjacent pages elsewhere in the codebase (e.g. the CLI's local
  loopback callback page in pkg/auth/oauth/flow.go).
• PR size: this exceeds the usual 400-line/10-file guideline, for the same reason Add RFC 8628 device authorization grant support #6647 did — splitting
  storage from the handlers that use it would leave an intermediate PR with dead code and no caller.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 80.66298% with 105 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.19%. Comparing base (97b81d8) to head (f3d64ab).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
.../authserver/server/handlers/device_verification.go	67.91%	60 Missing ⚠️
pkg/authserver/storage/redis.go	86.60%	15 Missing ⚠️
pkg/authserver/storage/memory.go	91.80%	10 Missing ⚠️
pkg/authserver/server/handlers/callback.go	72.00%	7 Missing ⚠️
...rver/server/handlers/device_verification_render.go	87.50%	5 Missing ⚠️
pkg/authserver/server/registration/dcr.go	84.00%	4 Missing ⚠️
pkg/authserver/server/handlers/handler.go	70.00%	3 Missing ⚠️
...r/server/handlers/device_verification_ratelimit.go	95.45%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #6682    +/-   ##
========================================
  Coverage   79.18%   79.19%            
========================================
  Files         791      794     +3     
  Lines       79518    80005   +487     
========================================
+ Hits        62965    63358   +393     
- Misses      16548    16642    +94     
  Partials        5        5            

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jhrozek]

Automated review of the device-flow verification page (RFC 8628). Overall the design is solid — PKCE/S256, OIDC nonce handling, IDP mix-up defense, explicit opaque-token-gated consent, and the DCR device_code-only carve-out all check out against spec. Two issues below should block merge: upstream tokens are never persisted for device-flow-authorized sessions, and an upstream access_denied during device-flow login isn't routed to the device-flow cleanup path. The rest are lower-severity/non-blocking.

[jhrozek]

All 6 findings from the previous review round were addressed with dedicated commits and accompanying tests: upstream tokens are now persisted under the device grant's final session id, upstream IDP denial now routes to the device-flow cleanup path, the verification-page rate limiter is now per-IP, the confirm-page initials handle multibyte names correctly, the upstream-selection ambiguity is now an explicit fail-fast, and the garbled doc comment is fixed. LGTM pending CI.