fix(plugin-auth): run the D5.1 /oauth2/authorize env-access gate for a signed bearer (#8102)

[os-zhuang]

Fixes#8102

ADR-0069 D5.1's cloud-as-IdP gate (oidcAuthorizeGate) is what enforces org-membership / app-assignment before the OIDC OP issues an authorization code. Its branch resolved the acting subject with an inline copy of the shared resolveActor — line for line the same logic, in a second place — and the two diverged the moment one of them was fixed.

#8101 taught resolveActor that a bearer credential must have its signature stripped before lookup: bearer() hands clients the signed form in the set-auth-token response header (the documented API-lane credential) and accepts it back, while session.token stores the unsigned value. The copy guarding /oauth2/authorize kept looking the signed credential up verbatim, and so resolved nothing.

Why this is security and not a lookup miss

The unresolved case at this endpoint is deliberately fail-open — a genuinely anonymous caller must fall through so the OP can redirect them to log in. So an authenticated caller holding the signed bearer was read as unauthenticated, and the env-access check was not denied but never evaluated at all.

Measured on the unfixed build, with the gate armed to DENY and a skip_consent client:

gateCalls=0 status=302
location=https://env.example.com/api/v1/auth/callback/objectstack-cloud?code=wCZn6Nsj4vY9pNucPs5ARYa8BTrjc2aS&state=envgate-8102

The gate was never invoked and an authorization code was actually issued to a subject it would have refused. The issue was written from a code reading and explicitly flagged that no live bearer-driven /oauth2/authorize had been measured; this closes that gap with a real request.

Impact stays bounded, as the issue itself said: oidcAuthorizeGate is set only on the cloud control plane (unset in open editions / self-host, where there is no gate at all), and the OP's authorize endpoint is normally browser/cookie-driven — the cookie branch always normalized and was never affected.

The fix

Delete the inline copy; call the shared this.resolveActor(ctx). Two resolution sites are what let them diverge, so correcting the copy in place would have left the same class open.

The fail-open default for genuinely unauthenticated callers is unchanged and deliberately preserved — that was never the defect, and the pin has a case asserting it still holds. resolveActor also returns activeOrgId; this gate deliberately does not consume it (the D5.1 host contract is (userId, clientId), and the control plane derives org membership from the user itself), and the site now says so rather than dropping it silently.

The pin

oidcAuthorizeGate previously appeared in no test file at all. The new dogfood gate drives /oauth2/authorize across three credential lanes against an armed, denying gate:

lane	on this build	on the unfixed build
cookie	refused	refused — control, cannot detect the defect
bearer, signed set-auth-token	refused	code issued — the pin
bearer, raw sign-in token	refused	refused — control

It closes the three ways this surface can be green while proving nothing:

• A cookie-driven pin passes before and after the fix, so the cookie and raw-token lanes are carried explicitly as armed-fixture controls. Exactly one lane flips.
• A gate that ALLOWS makes refusal and fall-through the same observation, so this one denies — "refused" and "issued a code" are then opposite outcomes.
• With no gate configured at all the file would be vacuously green, so it installs one through applyConfigPatch and asserts it was actually called, with the right userId. A status code alone cannot separate "denied" from "never evaluated".

Verification

• New pin: 7/7 green. Reverse-verified by restoring the inline copy from origin/main and rebuilding — exactly one lane went red, with the predicted diagnosis.
• @objectstack/dogfood full suite: 101 files, 680 passed / 3 skipped (re-run after merging main).
• @objectstack/plugin-auth: 45 files, 1069 passed.
• typecheck clean on both packages; ESLint clean.
• Gates: check:nul-bytes, check:changeset-gate-self-tests, check:docs-audit-scope, check:objectui-changeset, check:test-source-alias, check-changeset-no-major, plus the three off-list ratchets — check:query-options-erasure, check:type-check-debt (ledger not raised) and check:engine-double-contract.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 12, 2026 6:51pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth.

8 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/deployment/cli.mdx(via @objectstack/plugin-auth)
• content/docs/deployment/production-readiness.mdx(via @objectstack/plugin-auth)
• content/docs/kernel/contracts/cache-service.mdx(via @objectstack/plugin-auth)
• content/docs/kernel/services-checklist.mdx(via @objectstack/plugin-auth)
• content/docs/permissions/authentication.mdx(via @objectstack/plugin-auth)
• content/docs/permissions/sso.mdx(via @objectstack/plugin-auth)
• content/docs/plugins/index.mdx(via @objectstack/plugin-auth)
• content/docs/plugins/packages.mdx(via @objectstack/plugin-auth)

⛔ 2 release-owned page(s) also reference the affected code. These are read-only:

• content/docs/releases/implementation-status.mdx(via @objectstack/plugin-auth)
• content/docs/releases/v9.mdx(via @objectstack/plugin-auth)

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.