better-auth bearer plugin lets a bearer session silently shadow an impersonation the server just created — /admin/impersonate-user returns 200 and is a no-op for any bearer client

[yinlianghui]

Filed from the objectui seat as the server-side half of objectui#4467's measurement (defence-in-depth companion to the console-side fix ruled there — option A, the data lane adopting set-auth-token rotation). Contract question — objectstack lane; this seat lands no code here.

The mechanism (measured, better-auth 1.6.26)

1. A client authenticates with Authorization: Bearer <token>; better-auth's bearer plugin before-hook overwrites the request's session cookie with the bearer token (dist/plugins/bearer/index.mjs: setRequestCookie(headers, authCookies.sessionToken.name, decodedToken)).
2. POST /api/v1/auth/admin/impersonate-user succeeds (200), sets the impersonation session cookie, emits the impersonated token via set-auth-token, and records admin_session.
3. Every subsequent bearer-authenticated request resolves to the admin's session — the bearer beats the cookie the impersonation just set. The framework's own data routes resolve identity through the same path (runtime/src/security/resolve-session-principal.ts:51, http-dispatcher.ts:940), so writes during "impersonation" are attributed to the ADMIN.

Net: for any bearer client (the console after every normal sign-in), impersonation returns success and does nothing — the worst shape, a 200 no-op on a security-relevant endpoint.

The defence-in-depth ask (whichever fits the auth contract)

• Reject a bearer-authenticated impersonate-user unless the caller can adopt the rotation (or always: force clients through the rotation they must honor), OR
• invalidate/rotate the caller's bearer as part of impersonation, so the impersonated session is the only one that resolves afterwards.

Either makes "impersonation succeeded but did not take effect" structurally impossible server-side, independent of client lane discipline. The console-side fix (objectui#4467 option A) closes the live gap for this client; this card is about the class.

Also relevant: stop-impersonating resolves the admin via the admin_session COOKIE only — in cookie-blocked deployments (the exact context bearer() exists for) the exit path cannot work; worth deciding whether the endpoint should also honor a bearer-carried recovery.

Refs: objectui#4467 (measurement + console ruling), objectui#4304 (duplicate, closed).

Filed unassigned for the objectstack triage/decision lane.

---

Generated by Claude Code

[hotlong]

Triage: lands in the better-auth bridge / session resolution (plugin-auth hooks, runtime/src/security/resolve-session-principal.ts seam) ⇒ domain:identity; type Bug (a 200 no-op on a security endpoint violates the endpoint's declared contract). Dedup: only card in this repo for the class (objectui#4467 is the console half, objectui#4304 closed as its duplicate). ⇒ needs-user-decision — auth-flow shape is on the human floor, and the card's two remedies differ in client-visible contract.

Options (from the card, sharpened):

• A. Reject a bearer-authenticated impersonate-user (force clients through the cookie/rotation path). Loud, but the server has no signal for "this caller can adopt the rotation", so practical A = always reject — which breaks impersonation in cookie-blocked deployments, the exact context bearer() exists for.
• B. Rotate/invalidate the caller's bearer as part of impersonation, so the impersonated session is the only one that resolves afterwards; symmetrically, let stop-impersonating honor a bearer-carried recovery (today it resolves the admin via the admin_session cookie only, so the exit path is dead in cookie-blocked deployments).

Recommendation: B, including the stop-impersonating half.

• Platform long-term coherence: B closes the class server-side for every client lane; A only re-routes it and leaves cookie-blocked deployments without impersonation at all.
• Measured business pull: live — the console (a bearer client after every normal sign-in) got a silent no-op on a security-relevant admin action, with writes mis-attributed to the admin.
• AI-agent error-resistance: B makes "impersonation succeeded but did not take effect" structurally impossible; a client that ignores the rotation gets a loud 401, versus today's silently wrong identity on every subsequent write.
• Startup scope discipline: one mechanism on an existing endpoint pair, no new declared surface.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — rotation-based invalidation

Ruled by the maintainer in a live PM session, 2026-08-13 (session session_015XyMgCSMGGn9oSwbQEeWYg), verbatim: 「其他全部接受你的建议。」 — accepting the rotation direction as recommended.

Ruling: rotation, not refusal. POST /admin/impersonate-user must invalidate/rotate the caller's bearer as part of impersonation, so the impersonated session is the only one that resolves afterwards — "impersonation succeeded but did not take effect" becomes structurally impossible server-side. Refusal-based hardening is rejected: it would leave cookie-blocked deployments (the exact context bearer() exists for) permanently unable to impersonate. Additionally ruled: stop-impersonating must honour a bearer-carried admin_session recovery, not the cookie alone — otherwise the exit path cannot work in the deployments this card is about.

Implementation notes for dispatch:

• This wraps vendor internals (better-auth 1.7.0-rc.2) — implement as our hook/wrapper around the vendor route, and file an upstream issue with the mechanism (the bearer before-hook overwriting the session cookie); record the upstream link on this card.
• Coverage pins both directions: bearer client impersonates → subsequent bearer requests resolve to the impersonated principal (never the admin); stop-impersonating recovers the admin via bearer.
• Defence-in-depth companion: objectui#4467 option A (console adopts set-auth-token rotation) is the client half and stands regardless.

Label swap: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-zhuang]

Claim — starting implementation of the maintainer's rotation ruling.

• Session: session_01PEVB6w7D7uCszR9Mw1BL73
• Branch: claude/issue-8243-impersonation-bearer-rotation

Declared file surface (so disjointness from #8317's in-flight sys_member.role work is on the record):

• packages/plugins/plugin-auth/src/impersonation-bearer-rotation.ts (new)
• packages/plugins/plugin-auth/src/impersonation-bearer-rotation.test.ts (new)
• packages/plugins/plugin-auth/src/auth-manager.ts (modified — global before/after hook wiring)
• .changeset/*.md (new)

#8317 (branch claude/issue-8317-normalize-member-role, PR #8417) has surface auth-plugin.ts, index.ts, member-role-canonical.ts — verified against its branch diff, no overlap. In particular I am deliberately NOT exporting the new module from packages/plugins/plugin-auth/src/index.ts, which #8317 is editing.

---

Generated by Claude Code