Integrate DataOps with the shared Cognito browser login

[alexeygrigorev]

Integrate DataOps with the shared Cognito browser login

Status: in progress
Tags: enhancement, portal, frontend, backend, infra, testing, P1
Depends on: None
Blocks: None

Scope

Replace the production DataOps browser gate at ops.dtcdev.click with the shared serverless authentication service at https://auth.dtcdev.click. The DataOps Lambda remains the relying party: it starts Cognito authorization-code + S256 PKCE, handles https://ops.dtcdev.click/auth/callback, validates the returned identity, maps it to an existing enabled DataOps user by normalized email, and creates an opaque server-side DataOps session carried in a secure cookie.

The shared stack is already deployed as dtcdev-shared-auth in us-east-1. Its DataOps public client is registered for:

• callback: https://ops.dtcdev.click/auth/callback
• logout return: https://ops.dtcdev.click/
• flow/scopes: authorization code with openid email profile
• issuer: the UserPoolId/IssuerUrl output of that stack

The DataOps application and stack remain in this repository and deploy as dataops-v1 in eu-west-1 through .github/workflows/deploy-dataops-v1.yml with GitHub Actions OIDC. Shared Cognito ownership remains in ../aws-infra/sandbox/auth; this issue only consumes its non-secret contract.

This migration replaces browser Basic auth and the password-derived dtc_auth cookie. It must not weaken or silently replace the independent credentials used by machine-to-machine intake, integrations, webhooks, or existing bearer-session clients. Route-specific layered authorization remains route-specific.

Acceptance Criteria

• GET /login starts authorization at https://auth.dtcdev.click/oauth2/authorize using the configured DataOps client, exact callback URL, response_type=code, openid email profile, an unpredictable state and nonce, and an S256 PKCE challenge. OAuth transaction state is short-lived, one-time, integrity-protected, and never stored in browser localStorage.
• GET /auth/callback rejects missing, expired, replayed, or mismatched state; OAuth provider errors; missing codes; failed token exchanges; and invalid tokens without creating a DataOps session.
• The callback exchanges the code at /oauth2/token with the original PKCE verifier and validates the ID token signature against the issuer JWKS plus issuer, DataOps client audience, expiry/not-before, nonce, email, and email_verified. JWKS caching handles key rotation safely. Tokens, authorization codes, PKCE verifiers, and session identifiers are absent from response bodies, URLs after callback completion, and application logs.
• A successful callback normalizes the verified email and maps it to exactly one existing DataOps user. Unknown or disabled users receive a non-sensitive 403 response and are not auto-provisioned. The real local user ID is propagated to /api/me, role checks, assignment/notification filtering, and audit fields instead of the current portal-admin identity.
• A successful callback creates an opaque, cryptographically random, server-side session with a bounded absolute expiry. The browser receives only an HttpOnly; Secure; SameSite=Lax; Path=/ cookie; expired, deleted, fabricated, and revoked sessions are rejected. OAuth-created expiry enforcement must not silently invalidate or change the contract of existing non-browser bearer sessions.
• An authenticated browser session serves the portal, docs/content routes, and same-origin /api/* calls without Basic credentials or a browser-managed bearer token. Unauthenticated page requests redirect to /login; unauthenticated data/API requests return 401 without HTML or protected data.
• GET or POST /logout deletes the local server-side session, expires the cookie, and uses the Cognito logout endpoint with the registered DataOps logout URI. A logged-out cookie cannot be reused.
• Production no longer serves the DataOps username/password form, accepts Basic auth as a browser-session substitute, or requires BASIC_AUTH_USERNAME / the Basic-auth password secret at Lambda runtime. The legacy /api/auth/login endpoint remains unavailable in production portal mode. Deleting historical Secrets Manager resources is not required.
• Existing dedicated machine credentials and entry points keep their current isolation and authorization semantics, including email-document intake, bookkeeping ingestion/layered authorization, webhook/integration credentials, and existing bearer-session clients. A machine credential alone never becomes a browser session, and browser OAuth alone does not bypass a route's additional credential.
• infra/template.full.yaml exposes the shared auth base URL, issuer/user-pool contract, DataOps public client ID, callback URL, logout URL, and session-lifetime configuration as non-secret deployment configuration. The Lambda gains only permissions actually required by the implementation; no Cognito client secret or Google secret is copied into this repository or GitHub Actions.
• .github/workflows/deploy-dataops-v1.yml passes the auth configuration and continues to validate/build/deploy dataops-v1 exclusively through GitHub Actions OIDC. The workflow does not deploy or mutate dtcdev-shared-auth, and the application is not manually deployed for this issue.
• Automated tests cover authorization parameter construction, PKCE/state/nonce lifecycle and replay rejection, token/JWKS validation failures and key refresh, local-user mapping (enabled/disabled/unknown/case normalization), session creation/expiry/logout, page-vs-API unauthenticated behavior, and authenticated /api/me/role behavior. Token and JWKS HTTP calls are stubbed; automated tests do not require a live Cognito account.
• Regression tests prove each existing machine credential path and existing bearer-session path retains its prior allow/deny boundary, including invalid/missing credential cases and routes with layered credentials.
• Tester runs npm --prefix backend test, npm --prefix backend run typecheck, npm --prefix backend run build, npm --prefix backend run test:e2e, make sam-validate, and make sam-build, reporting exact commands, exit codes, and test counts. Playwright captures and inspects screenshots for the signed-out entry/error state and the authenticated DataOps workspace; no screenshot may show a 404, error page, broken layout, overlap, or leaked credential.
• [HUMAN] After deployment, an administrator-created Cognito username/password user can complete the real hosted-login flow, return to https://ops.dtcdev.click/auth/callback, use the portal as the matching DataOps user, log out, and fail to reuse the old session. Capture the tested identity, time, browser result, and screenshot without recording credentials or tokens.
• [HUMAN] After the shared stack owner enables Google, a real @datatalks.club Google account can sign in and a non-@datatalks.club Google account is rejected. Record the result without exposing credentials or tokens. Google is enabled on the shared user pool; this real-account allow/deny check keeps the issue open with the human label until a human verifies both account classes.

Test Scenarios

Scenario: Signed-out operator starts secure login

Given: No valid DataOps session cookie exists
When: The operator opens a protected portal page
Then: DataOps redirects through /login to the shared authorize endpoint with fresh state, nonce, and S256 PKCE while an API request receives JSON 401

Scenario: Valid shared identity becomes the correct local operator

Given: Cognito returns a valid token for an enabled DataOps user email
When: The callback validates and exchanges the authorization code
Then: DataOps creates a bounded opaque session, redirects to a clean same-origin page, /api/me returns that local user, and authorization/audit behavior uses that user's ID and role

Scenario: Callback tampering or replay fails closed

Given: State, nonce, PKCE data, token claims, signature, or transaction expiry is invalid, or a completed callback is replayed
When: The callback is requested
Then: No session is created, a safe error is returned, and no code/token/verifier/session value is logged or rendered

Scenario: Unknown or disabled shared identity is denied

Given: A valid Cognito identity has no unique enabled DataOps user mapping
When: The callback completes
Then: DataOps returns 403 without auto-provisioning or revealing whether another account exists

Scenario: Session expiry and logout revoke access

Given: An operator has a valid OAuth-created DataOps session
When: The session expires or the operator logs out
Then: The server-side session and cookie no longer authorize portal or API access and Cognito logout returns to the registered DataOps URI

Scenario: Non-browser credentials retain their boundaries

Given: Existing intake, integration, webhook, layered, and bearer-session clients
When: They call their current routes with valid, missing, and invalid credentials
Then: Their pre-migration allow/deny behavior is preserved, additional credentials are still enforced, and none of those credentials grants browser access

Scenario: CI deploys the relying-party configuration

Given: The auth change reaches main
When: the DataOps deployment workflow runs
Then: tests and SAM validation/build pass, GitHub OIDC deploys dataops-v1 in eu-west-1, and the workflow does not mutate the shared auth stack in us-east-1

Out of Scope

• Creating, redeploying, or changing the shared Cognito stack in ../aws-infra, including the Dapier, Datamailer, AI Engineering Gym, and AI System Design Studio clients.
• Creating Google OAuth credentials or enabling the Google identity provider; those require the shared-stack owner and real external credentials.
• Auto-provisioning DataOps users from Cognito, synchronizing Cognito groups to DataOps roles, or building user lifecycle administration across services.
• Migrating existing DataOps password hashes into Cognito or deleting historical Basic-auth secrets from AWS Secrets Manager.
• Replacing route-specific API keys, webhook signatures, integration credentials, or bearer-session APIs with browser OAuth.
• Redesigning the DataOps workspace beyond the login, callback, logout, and authentication error states needed for this migration.

Dependencies

• External contract (already available): CloudFormation stack dtcdev-shared-auth in us-east-1, auth base https://auth.dtcdev.click, its IssuerUrl/JWKS outputs, and the DataOps public client registered for https://ops.dtcdev.click/auth/callback.
• Deployment contract: dataops-v1 remains in eu-west-1 and is deployed by .github/workflows/deploy-dataops-v1.yml through arn:aws:iam::817685572750:role/dataops-github-actions-deploy.
• Local identity contract: DataOps users, roles, and disabled status in the existing users table remain the authorization source after Cognito proves identity.
• Google federation is enabled on the shared user pool. The Dapier, DataOps, AI Engineering Gym, AI System Design Studio, and Datamailer clients all support both COGNITO and Google. Infrastructure enablement is complete; the remaining dependency is the unchecked [HUMAN] live allow/deny verification with real in-domain and out-of-domain Google accounts.

[alexeygrigorev]

Software Engineer handoff

Implementation is ready for Tester review in the uncommitted worktree
/home/alexey/git/dataops/.tmp/worktrees/worktree-issue-119 on branch
worktree-issue-119.

Implemented

• Added Cognito authorization-code login with S256 PKCE, random state/nonce,
  a short-lived one-time DynamoDB transaction, and a separate HttpOnly binding
  cookie. Transaction records store hashes rather than the browser state or
  binding value.
• Added token exchange and RS256 ID-token verification against cached issuer
  JWKS, including refresh on missing/rotated keys or signature failure;
  validates algorithm/key use, signature, issuer, audience, expiry, not-before,
  nonce, token use, email, and email verification.
• Maps normalized verified email to exactly one existing enabled DataOps user.
  Unknown, disabled, or ambiguous identities receive the same non-sensitive
  403 and are never provisioned.
• Added cryptographically random, opaque server-side browser sessions with
  absolute expiry and DynamoDB TTL. The cookie is
  HttpOnly; Secure; SameSite=Lax; Path=/; old bearer sessions without the new
  expiry fields retain their prior contract.
• Propagates the real local user ID/role through /api/me and existing route
  authorization instead of the browser portal-admin fallback.
• Added local revocation plus Cognito logout. Reusing the deleted cookie fails.
• Removed the production Basic/password-derived browser gate and old login
  form; /api/auth/login remains unavailable in portal mode. Basic credentials
  cannot serve a browser page or authorize a portal API.
• Preserved dedicated email-document intake before browser auth, existing
  bearer clients, portal-broker credentials, and route-specific layered
  authorization. Bookkeeping retains both bearer-session and ingestion-key
  checks in portal mode. Bookkeeping, calendar, and newsletter importers now use
  their existing bearer-session option instead of the removed Basic path.
• Added non-secret CloudFormation parameters/env for auth base, user pool,
  issuer, JWKS, client, callback, logout, and session lifetime. No Cognito client
  or Google secret is present, and no new AWS permission was added.
• Updated the GitHub Actions OIDC deploy workflow to pass every auth parameter
  to dataops-v1; it does not deploy or mutate dtcdev-shared-auth.
• Updated auth/runtime/importer documentation and infrastructure contract
  assertions.

Changed files

• Auth/runtime: backend/src/auth/browserAuth.ts,
  backend/src/db/sessions.ts, backend/src/db/users.ts,
  backend/src/docs/portal.ts, backend/src/router.ts,
  backend/src/types.ts
• Machine clients: backend/scripts/import-bookkeeping.ts,
  backend/scripts/import-calendar.ts,
  backend/scripts/import-newsletter-slots.ts
• Tests: backend/tests/browser-auth.test.ts,
  backend/tests/docs-portal.test.ts, backend/tests/portal-auth.test.ts,
  backend/tests/api-bookkeeping.test.ts,
  backend/tests/import-bookkeeping.test.ts,
  backend/tests/newsletter-slots.test.ts, backend/tests/calendar.test.ts,
  backend/tests/bookkeeping-production-frontend.test.ts,
  tests/infra/test_template.py
• Deployment: infra/template.full.yaml,
  .github/workflows/deploy-dataops-v1.yml
• Docs: docs/architecture.md, docs/calendar.md,
  docs/local-development.md, docs/v1-runtime-architecture.md

Verification run by SWE

• npm --prefix backend test — exit 0; 1,190 tests passed, 0 failed.
• npm --prefix backend run typecheck — exit 0.
• npm --prefix backend run build — exit 0.
• npm --prefix backend run test:e2e — exit 0; 342 Playwright tests passed,
  0 failed.
• uv run --with pytest python -m pytest tests/infra/test_template.py — exit
  0; 19 tests passed, 0 failed. This includes exact GitHub OIDC and all eight
  shared-auth deploy-parameter assertions.
• make sam-validate — exit 0; infra/template.full.yaml is a valid SAM
  template.
• make sam-build — exit 0; BackendFunction package built successfully.
• Focused auth/portal/machine regression run — exit 0; 63 tests passed, 0
  failed.
• git diff --check — exit 0.

Acceptance status / remaining checks

• The first 13 implementation and automated-verification acceptance criteria
  are checked in the issue body.
• Tester must independently rerun the mandated commands and capture/read the
  signed-out auth-error and authenticated workspace screenshots. SWE did not
  claim the Tester-only checkbox or create review screenshots.
• No application or shared-auth stack was manually deployed. Deployment remains
  exclusively through the GitHub Actions OIDC workflow after approved merge.
• Both [HUMAN] hosted-login checks remain unchecked. After deployment, verify
  a real administrator-created Cognito password user, logout/reuse denial, an
  allowed @datatalks.club Google account, and rejection of a Google account
  outside the domain without recording credentials, codes, tokens, or session
  values.
• The issue should receive the human label and remain open after code ships
  until those checks are recorded.

No commit or push was made.

[alexeygrigorev]

CHANGES REQUESTED

Independent Tester verification found one exploitable authorization failure and one incomplete uniqueness boundary. The implementation must return to SWE before PM acceptance. I did not commit, push, deploy, or check the Tester acceptance box.

Blocking security finding

In production portal mode, /api/me trusts the inbound x-user-id header before validating a bearer session:

const authenticatedUserId = headerValue(event.headers, 'x-user-id') || portalUserId;

handlePortal deliberately allows a request carrying any bearer-shaped header to continue to the legacy bearer validator. That means a caller can send a fabricated bearer value plus the ID of an existing user and receive that user's profile without a valid cookie, bearer session, or broker secret.

Reproduction (local in-memory tables, portal mode, no auth bypass):

GET /api/me
Authorization: Bearer fabricated-token
x-user-id: victim-admin

Actual: HTTP 200 with the victim-admin admin record.

Expected: HTTP 401. A valid bearer session with a mismatched x-user-id must resolve to the bearer session's user, never the caller-supplied header.

The reproduction command exited 0 and printed:

{"statusCode":200,"body":"{\"user\":{\"id\":\"victim-admin\",...\"role\":\"admin\"}}"}

Required fix: derive /api/me identity only from (a) handlePortal's verified browser userId, (b) a broker identity after the portal-secret check, or (c) a successfully loaded bearer session. Do not treat a raw inbound x-user-id as authenticated. Add regressions for a fabricated bearer plus x-user-id, and for a valid bearer plus a different x-user-id.

Additional identity-mapping gap

getUsersByNormalizedEmail performs only one DynamoDB ScanCommand. DynamoDB Scan pages at 1 MiB, so a matching or duplicate user beyond LastEvaluatedKey is ignored. That does not prove the acceptance requirement that the verified email maps to exactly one existing user across the table. Paginate to exhaustion (or use an indexed normalized-email key) and add a multi-page duplicate regression.

Required command evidence

• npm --prefix backend test — exit 0; 1,190 tests, 1,190 passed, 0 failed.
• npm --prefix backend run typecheck — exit 0.
• npm --prefix backend run build — exit 0.
• npm --prefix backend run test:e2e — exit 0; 342 Playwright tests passed, 0 failed.
• make sam-validate — exit 0; infra/template.full.yaml valid.
• make sam-build — exit 0; BackendFunction build succeeded.
• uv run --with pytest python -m pytest tests/infra/test_template.py — exit 0; 19 passed, 0 failed.
• Focused auth/portal/machine regression command (browser-auth, docs-portal, portal-auth, bookkeeping, calendar, and newsletter suites) — exit 0; 63 passed, 0 failed.
• git diff --check — exit 0.

The green suites do not cover the spoofed-header case above, so they do not establish the affected acceptance criteria.

Screenshot evidence

• .tmp/screenshots/issue-119/signed-out-auth-error.png — 1440x900, SHA-256 5e74d7ffe504e4a5cd755e8afb67d9de8606aff440783fb75937a90c795765b7; inspected: HTTP 400 safe sign-in error, no 404, overlap, credential, code, token, or session value.
• .tmp/screenshots/issue-119/authenticated-workspace.png — 1440x900, SHA-256 6f9e1d3424ba2e107311b95e29793a450f2a33e343850a2e123819aaf2f743be; inspected: authenticated Tasks / Work Queue empty state, /api/me returned the seeded local admin, no 404, error page, overlap, or leaked credential.

The screenshot harness also verified signed-out / -> 302 /login, signed-out /api/tasks -> JSON 401, callback-without-state -> safe 400, authenticated workspace -> 200, and authenticated /api/me -> the mapped local user. The harness itself exited 0.

Acceptance-criterion assessment

• Authorization start, callback validation, PKCE/state/nonce, JWT/JWKS checks, sessions/logout, page/API separation, Basic-auth removal, machine credential isolation, stack parameters, OIDC deploy wiring, and visual states have positive automated evidence.
• The real-local-user and credential-isolation criteria are not accepted because /api/me can be spoofed as described.
• Exact-one-user mapping is not accepted because the scan does not paginate.
• Both real hosted-login criteria remain [HUMAN] and were not attempted by Tester.

Please send the fixes back for an independent Tester rerun.

[alexeygrigorev]

Software Engineer retest handoff

The Tester-requested changes are implemented in the uncommitted worktree
/home/alexey/git/dataops/.tmp/worktrees/worktree-issue-119 on branch
worktree-issue-119.

Changes made

• Removed the raw x-user-id trust path. Outside the explicit test-only auth
  bypass, every casing of this inbound header is deleted before authorization
  and is replaced only after browser-session, signed portal-broker, or bearer-
  session verification.
• /api/me now resolves and returns an existing enabled DataOps user only from
  a verified browser/broker identity or a valid bearer session. A fabricated
  bearer plus an existing user ID is rejected.
• Preserved valid legacy bearer sessions in portal mode while ensuring a
  mismatched client-provided x-user-id cannot override the session user.
• Made normalized-email lookup scan every DynamoDB page before deciding whether
  there is exactly one match, so identities on later pages are found and
  duplicates split across pages still fail closed in the callback flow.
• Added regression coverage for /api/me, another protected API route, bearer
  identity precedence, later-page matches, and cross-page ambiguity.

Verification after the fixes

• Focused auth/user regression run: 32 tests passed, 0 failed.
• npm --prefix backend test: 1,195 tests passed, 0 failed.
• npm --prefix backend run typecheck: passed.
• npm --prefix backend run build: passed.
• git diff --check: passed.

No UI or infrastructure files changed as part of this retest fix, so the prior
green E2E (342/342), infrastructure tests (19/19), SAM validation, and SAM build
remain applicable. No commit or push was made.

[alexeygrigorev]

TEST PASS

The two previously blocking findings are fixed and independently verified. All agent-verifiable acceptance criteria now pass. No commit, push, or deployment was performed.

Security retest

• Re-ran the former exploit in production-like portal mode against an existing admin: Authorization: Bearer fabricated-token plus raw x-user-id: victim-admin now returns HTTP 401 JSON {"error":"Unauthorized"}. Reproduction command exit 0.
• A fabricated bearer plus raw x-user-id also fails on another protected API route.
• A valid legacy bearer plus a mismatched raw x-user-id resolves to the bearer session's actual user, not the caller-supplied identity.
• Signed portal-broker identity still requires the shared secret and resolves an existing enabled local user.
• Normalized-email lookup now follows LastEvaluatedKey across every Scan page. Focused tests prove both a unique match on a later page and duplicate matches split across pages; the latter reaches the callback as ambiguous and fails closed.

Command evidence

• NODE_ENV=test SKIP_AUTH=true node --import tsx --test tests/browser-auth.test.ts tests/portal-auth.test.ts tests/users.test.ts (from backend/) — exit 0; 32 passed, 0 failed.
• npm --prefix backend test — exit 0; 1,195 passed, 0 failed, 173 suites.
• npm --prefix backend run typecheck — exit 0.
• npm --prefix backend run build — exit 0.
• npm --prefix backend run test:e2e — exit 0; 342 Playwright tests passed, 0 failed.
• uv run --with pytest python -m pytest tests/infra/test_template.py — exit 0; 19 passed, 0 failed.
• make sam-validate — exit 0; infra/template.full.yaml is a valid SAM template.
• make sam-build — exit 0; BackendFunction build succeeded.
• npx tsx .tmp/tester-119/capture-auth-evidence.ts — exit 0; signed-out root 302 to /login, signed-out API JSON 401, missing-state callback safe 400, authenticated workspace 200, mapped /api/me 200.
• git diff --check — exit 0.

Screenshot evidence

• .tmp/screenshots/issue-119/signed-out-auth-error.png — 1440x900, SHA-256 5e74d7ffe504e4a5cd755e8afb67d9de8606aff440783fb75937a90c795765b7.
• .tmp/screenshots/issue-119/authenticated-workspace.png — 1440x900, SHA-256 6f9e1d3424ba2e107311b95e29793a450f2a33e343850a2e123819aaf2f743be.

Both screenshots were regenerated and read after the fixes. The signed-out state is the safe local sign-in error with a retry link. The authenticated state is the DataOps Tasks / Work Queue empty state. Neither shows a 404, error page, broken layout, overlap, authorization code, token, session identifier, or credential.

Acceptance criteria

1. Authorization parameters, unpredictable state/nonce, S256 PKCE, short-lived server-side transaction: pass.
2. Missing/expired/replayed/mismatched state and provider/token failures: pass.
3. RS256/JWKS, issuer/audience/time/nonce/token-use/email verification and key refresh: pass.
4. Exact enabled local-user mapping, case normalization, unknown/disabled/ambiguous denial, and multi-page uniqueness: pass.
5. Opaque bounded server session, secure cookie, expiry/revocation, legacy bearer compatibility: pass.
6. Authenticated portal/API access and signed-out page/API separation: pass.
7. Local and Cognito logout plus reuse denial: pass.
8. Production Basic/password form and legacy portal login removal: pass.
9. Email intake, bookkeeping layered credentials, importers, portal broker, and legacy bearer isolation: pass.
10. Non-secret SAM auth configuration and least-privilege contract: pass.
11. GitHub Actions OIDC validation/build/deploy wiring and shared-stack non-mutation: pass.
12. Required automated auth coverage: pass.
13. Machine and bearer regression boundaries, including raw-header spoof rejection: pass.
14. Tester command and visual evidence criterion: pass; checkbox updated.
    15-16. Real hosted password and Google flows remain [HUMAN], were not attempted by Tester, and should keep the issue open with the human label after shipping.

READY FOR PM ACCEPTANCE

[alexeygrigorev]

REJECTED

The core Cognito integration, local identity mapping, session model, machine-credential compatibility, and GitHub Actions OIDC deployment contract are strong, and Tester supplied the required full-suite and screenshot evidence. PM acceptance is still blocked by two security/product-flow gaps in the relying-party journey.

1. Post-login return target is not guaranteed to stay on DataOps

safeReturnTo accepts any value beginning with one slash except //. It therefore accepts a decoded value such as /\evil.example. Browsers apply URL backslash normalization for HTTPS URLs: new URL('/\\evil.example', 'https://ops.dtcdev.click').href resolves to https://evil.example/. After a successful callback, the implementation copies this value directly into the Location header.

This violates the test scenario requiring callback completion to redirect to a clean same-origin page and creates a post-authentication open redirect.

Required change:

• Canonicalize and validate return_to against the DataOps callback/origin, not only string prefixes.
• Reject backslashes, control characters, protocol-relative forms, auth endpoints, and any candidate whose parsed origin differs from https://ops.dtcdev.click; fall back to /.
• Add regressions covering decoded backslash forms (including /\evil.example), //evil.example, absolute URLs, and valid same-origin paths.

2. Failed callbacks leave the authorization code and state in the browser URL

When state/binding/token exchange/token validation/account mapping fails, handleCallback returns the HTML error response directly from /auth/callback?code=...&state=.... The generic body does not print those values, but the completed error page remains on a URL containing them, and the error response lacks a Referrer-Policy: no-referrer header. Clicking Try again can consequently carry the callback URL as a same-origin referrer.

This does not meet the unchecked acceptance criterion requiring authorization codes and session-sensitive values to be absent from URLs after callback completion.

Required change:

• Complete callback failures by redirecting to a clean same-origin error route without OAuth query data (or an equivalent mechanism that reliably removes it before rendering).
• Apply Cache-Control: no-store and Referrer-Policy: no-referrer to the clean error journey.
• Keep provider details and account-existence information generic.
• Add a regression starting with a valid transaction and a failed token exchange/validation, asserting that the rendered/final error URL contains no code, state, token, verifier, or session value.

User-visible error state

The regenerated signed-out-auth-error.png is functional, but it is raw browser-default HTML on a blank page and visually reads like an unstyled server failure rather than part of DataOps. The authentication error state is explicitly within this issue's scope and the PM gate requires usable, coherent error states. Render a minimal DataOps-consistent error panel with clear retry action and accessible focus/heading treatment; do not expose technical provider details.

Retest required

After the fixes, Tester must independently rerun the affected auth/security tests plus the issue's full required commands, regenerate and inspect the signed-out error screenshot, and reconfirm the authenticated workspace screenshot. The two [HUMAN] hosted password/Google checks remain correctly deferred and should not block agent acceptance after these changes.

I unchecked the affected ID-token/callback URL privacy criterion. I did not change code, commit, push, deploy, or add the human label.