The D5.1 `/oauth2/authorize` env-access gate silently does not run for a signed bearer credential — its inline token lookup is a stale copy of `resolveActor`

[os-zhuang]

Blocked-by: #8049

Found while fixing #8049 (PR #8101). Not fixed there — different endpoint, kept out of scope deliberately.

What

packages/plugins/plugin-auth/src/auth-manager.ts resolves a session token from the request in two places:

• resolveActor (~:3806) — the shared, documented, hook-order-independent resolver, used by the /sso/register admin gate and (as of fix(plugin-auth): /auth/change-password clears the force-change flag and enforces password-reuse on the bearer lane (#8049) #8101) /change-password;
• an inline copy inside the /oauth2/authorize branch of the same global before-hook (~:1341-1362), guarding ADR-0069 D5.1's cloud-as-IdP oidcAuthorizeGate.

The two are line-for-line the same logic. #8101 fixed one bug in the shared one and left the copy untouched, so they have now diverged.

The defect

Both copies look the session up by sys_session.token, which stores the unsigned value. The cookie branch strips the signature (decodeURIComponent(cm[1]).split('.')[0]); the bearer branch does not. But better-auth's bearer() plugin hands clients the signed token.signature form in the set-auth-token response header — the documented API-lane credential — and accepts it back. So a caller presenting that credential resolves to nothing.

On /oauth2/authorize the unresolved case is deliberately fail-open — the comment reads "Unauthenticated → fall through so the OP redirects to login", and the branch is skipped entirely when gateUserId is undefined:

if (gateUserId) {
 const allowed = await this.config.oidcAuthorizeGate({ userId: gateUserId, clientId: String(clientId) });
 if (!allowed) { ... ENV_ACCESS_DENIED ... }
}

So an authenticated caller holding a signed bearer is treated as unauthenticated and the env-access (org-membership / app-assignment) check never evaluates. That is the same shape as #8049 one endpoint over: a declared security control that is enforced for one credential spelling and silently absent for the other.

The author clearly intended bearer to work here — the comment on the branch says "or immediately for a bearer/cookie session" and the fallback exists precisely because getSessionFromCtx misses bearer requests at this hook.

Severity note

oidcAuthorizeGate is only set on the cloud control plane (unset in open editions / self-host ⇒ no gate at all), and the OP's authorize endpoint is normally browser/cookie-driven, so the cookie path — which does normalize — is the common one. I have not measured a live bearer-driven /oauth2/authorize request; the claim above is read off the code plus the token-shape measurement from #8049 (set-auth-token = token.signature, sys_session.token = unsigned; measured on better-auth 1.7.0-rc.2). Grading is the triage round's call, not mine.

There is also no test coverage: oidcAuthorizeGate appears in auth-manager.ts only (declaration + the two use sites), with no occurrences in any *.test.ts.

Suggested fix

Delete the inline copy and call this.resolveActor(ctx) — after #8101 it is correct for both bearer spellings and returns the activeOrgId too. That removes the second resolution site rather than fixing it twice, which is what let these diverge in the first place. Hence Blocked-by: #8049: the shared resolver only became correct in that PR.

A regression pin should drive /oauth2/authorize with a signed bearer against a gate configured to deny, and assert the request is refused rather than falling through.

[hotlong]

Triage: domain:identity (fix lands in packages/plugins/plugin-auth/src/auth-manager.ts), pm:blocked on the card's own Blocked-by: #8049 line — the suggested fix (delete the inline copy, call resolveActor) is only correct once PR #8101 lands, so this waits for that merge and the unlock scan returns it. Type: Bug (declared control — the D5.1 env-access gate — silently unenforced for the documented API-lane credential spelling).

Grading note for the unlock re-check: severity is honestly bounded by the card itself (gate only configured on the cloud control plane; cookie path — which normalizes — is the common one; no live bearer-driven /oauth2/authorize measured). At requeue time re-verify on the merged ref that (a) #8101 didn't already absorb this site, and (b) the inline copy still exists at ~:1341-1362. The regression pin the card names (signed bearer + deny-configured gate ⇒ refused, not fall-through) should be a dispatch requirement — this is exactly the enforced-for-one-spelling class where a green suite proves the wrong thing.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[os-zhuang]

Unblocked by the unlock scan, and claimed in the same action. Blocked-by: #8049 is discharged — PR #8101 MERGED as 36c2f002d at ~17:12Z, landing-verified.

Claim: PM loop round 6 (domain:identity seat #6022)
Session: session_01PEVB6w7D7uCszR9Mw1BL73
Branch: claude/issue-8102-oauth2-authorize-inline-token-lookup
Worktree: objectstack-issue-8102
Domain: domain:identity
File surface: packages/plugins/plugin-auth/src/auth-manager.ts — the /oauth2/authorize branch's inline token lookup (:1329-1364) + tests + a changeset.
Container & model: M, mode:subagent, model: opus — small diff, but it restores a security control that is currently fail-open, and the pin is the hard part.
Serial constraints cleared: plugin-auth is free. #8017, #8101 and #8121 all merged this shift; the one live sibling dev is #7795 in plugin-sharing.

⚠️ Going straight from pm:blocked to pm:dispatched in one label write, deliberately: a requeue-then-claim would leave a window where the card reads dispatchable to another seat. One atomic transition, no half-state.

Both of triage's re-check conditions, run on the merged ref

The grading note asked for two readings at requeue time. Neither was assumed:

triage's condition	reading on origin/main
(a) did #8101 already absorb this site?	No. resolveActor(ctx) at :1302 serves the /sso/register branch; the /oauth2/authorize branch is separate
(b) does the inline copy still exist?	Yes — gateUserId with its own lookup at :1329-1364 (the card said ~:1341-1362; drifted, as everything in this file has today)

And the divergence the card predicted is now real and visible: resolveActor gained its signature-stripping fix at :3832 (const unsigned = …), while the inline copy did not. Two resolution sites, one fixed, one not — exactly the shape that produced this card.

Why this ranks now rather than later, despite honest severity bounds

The card bounds its own severity carefully — oidcAuthorizeGate is set only on the cloud control plane, the authorize endpoint is normally cookie-driven, and no live bearer-driven request was measured. I am not inflating that.

But the failure mode is the worst-shaped one available: the unresolved case is deliberately fail-open ("Unauthenticated → fall through so the OP redirects to login"), so an authenticated caller holding the documented API-lane credential is treated as unauthenticated and the env-access check never evaluates. A control that is enforced for one credential spelling and silently absent for the other, with zero test coverage (oidcAuthorizeGate appears in no *.test.ts) — that is #8049's lesson one endpoint over, and #8049 is the card that proved the shape is real rather than theoretical.

---

Generated by Claude Code