fix(auth): require step-up for durable user access (#360)

[mforce]

Closes #360.

Summary

• Require a fresh, single-use step-up grant for every interactive user creation, administrative password reset, and role change, regardless of the created/target/requested role.
• Preserve trusted simulation provisioning through an explicit non-HTTP identity path instead of an interactive-handler bypass.
• Make all three Users dialogs collect and consume recent-auth proof consistently, and synchronize Help, glossary, API comments, and en/es/tl copy.
• Keep display-name edits and flock assignments explicitly outside this remediation; the durable flock-scope boundary is tracked in Require step-up for durable flock-scope changes #606.

Security impact

This closes the path where a stolen Owner access token could create a durable non-Owner credential, replace a non-Owner password, or change an account's role without recent password proof. The creation/reset flaw affects releases v0.0.1 through v0.0.4; the role-change sibling affects v0.0.4.

Repository-local audit data was unavailable, so this PR does not claim that production exploitation was ruled out.

Verification

• Exact runbook backend gate: locked restore; NuGet production advisory gate clean at high+; Release build clean with 0 warnings/errors; 1,981 .NET tests passed (AppHost 10, Domain 345, Application 167, API integration 1,459); schema docs up to date.
• Exact runbook frontend gate: vulnerability-gate tests 26/26; lockfix tests 9/9; npm production advisory gate clean at high+; Vitest 1,959/1,959 across 87 files; coverage 91.25% statements, 83.38% branches, 87.67% functions, 94.01% lines; production build and service-worker verification passed. The existing large-chunk warning remains.
• Focused original/sibling PoC block: 7/7 passed, covering missing-proof denial with unchanged user/password/role state and valid-grant success.
• All eight transient mutations were independently proven red for the intended discriminator and restored green: M1, M1s, M2, M2-order, M3, M4, M5, and M6. No mutation/debug marker remains.
• Non-CI caller inventory completed: the simulation seeder's cast-user write path now calls the trusted identity port directly; k6 only reads /api/v1/users or probes its authorization; Playwright only exercises Users navigation/read authorization and the corresponding test mutant. No k6 or Playwright user-access write caller requires a contract update.

Hosted-only dependency review, CodeQL, image/lock-drift checks, Trivy, container boot/readiness, publishing, and attestation remain CI evidence.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b7a5a78d4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Cancel mutations whose step-up dialog was dismissed

When /auth/step-up is slow, Cancel, Close, and Escape remain enabled, but dismissing the dialog during this await does not invalidate its continuation. Once the grant arrives, a canceled Worker creation is still sent; if the create dialog was reopened meanwhile, the old continuation also calls closeCreate() and clears the new form. The new unconditional awaits in onSetPassword and onChangeRole likewise send canceled resets and role changes. Check a dialog generation or active target after stepUp and before issuing the write, as onChangeEmail already does.

Useful? React with 👍 / 👎.

[mforce]

Fixed in 8bf2b0a (fix(web): guard dismissed step-up continuations), covered by 43fd92f and 48f9e79. Each of onCreate/onSetPassword/onChangeRole now tracks a dialog generation (onSetPassword/onChangeRole also pin the target id) captured at open time; after the stepUp() await (and again after the write) an isCurrentDialog() check short-circuits if the dialog was dismissed or reopened for a different target/attempt, matching the pattern onChangeEmail already used. Verified: dismissing mid-await no longer issues the write, and reopening for a new target/attempt no longer lets the stale continuation call close*() or report an error against the new dialog. Landed before merge (PR #607, merged as f767dce).

[gitguardian]

⚠️ GitGuardian has uncovered 5 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35146328	Triggered	Generic Password	8bf2b0a	web/src/routes/UsersPage.test.tsx	View secret
35010655	Triggered	Generic Password	43fd92f	web/src/routes/UsersPage.test.tsx	View secret
35146328	Triggered	Generic Password	43fd92f	web/src/routes/UsersPage.test.tsx	View secret
35146328	Triggered	Generic Password	43fd92f	web/src/routes/UsersPage.test.tsx	View secret
35146328	Triggered	Generic Password	48f9e79	web/src/routes/UsersPage.test.tsx	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[mforce]

@codex the dialog-dismissal race you flagged (comment #3866354731, web/src/routes/UsersPage.tsx) is addressed in 8bf2b0a, with coverage added in 43fd92f and 48f9e79 — both landed before merge (f767dce). Reply left on the original thread with details.

[chatgpt-codex-connector]

Confirmed—the dismissal race is resolved in the merged code.

• Create, password-reset, and role-change operations capture the active dialog generation and stop after the asynchronous step-up request if that dialog was dismissed or superseded. They also avoid allowing stale post-write continuations to close or modify a reopened dialog. web/src/routes/UsersPage.tsxL280-L316 web/src/routes/UsersPage.tsxL390-L424 web/src/routes/UsersPage.tsxL448-L474
• The regression tests explicitly hold step-up issuance pending, dismiss and reopen each dialog, then resolve the old grant. They verify that no stale write occurs and that the reopened form remains intact. web/src/routes/UsersPage.test.tsxL511-L554 web/src/routes/UsersPage.test.tsxL556-L601 web/src/routes/UsersPage.test.tsxL603-L635
• No further code changes or follow-up PR are needed.

Verification

• ✅ git log --oneline -8 — confirmed the fix is present in merge commit f767dce.
• ✅ git status --short --branch — working tree is clean.
• ⚠️ npm test -- --run src/routes/UsersPage.test.tsx — could not execute because the installed Node 20 runtime rejects the configured --no-experimental-webstorage option; this is an environment/runtime mismatch, not a test failure.
• ❌ npm test -- --run web/src/routes/UsersPage.test.tsx — initial invocation used a repository-relative path while running from web/, so Vitest found no matching test file.

View task →