[finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it

[claude]

Filed by the #14150 measurement seat (read-only card, session session_01AUF1NoViznQK32gqpK8wS8, scratchpad key issue-14150-knife1). Out of scope for that card — recording only, unassigned, for the finding box to grade. Measured on origin/main at e854a531a.

What was measured

@better-auth/scim@1.7.2 — the version this repo pins (packages/plugins/plugin-auth/package.json:29, ^1.7.2) and resolves (pnpm-lock.yaml:9632; installed node_modules/@better-auth/scim/package.json reports 1.7.2) — contains no ban code path at all. The substring ban occurs zero times anywhere in the published package:

grep -ro "ban" node_modules/@better-auth/scim/dist | wc -l   →   0

What active: false does instead, dist/index.mjs:4196-4231 (reconcileUser):

1. calls the OPTIONAL host callback options.identity.reconcileUser(state, ...) — typed at dist/index.d.mts:267 as "Reconciles global enabled or disabled state inside the SCIM transaction.";
2. if (!active) await input.auth.internalAdapter.deleteUserSessions(userId).

plugin-auth passes no identity option. The only two members handed to scim() are connections: [] and authentication.verifyBearerToken — packages/plugins/plugin-auth/src/auth-manager.ts:3256-3270. And reconcileUser appears nowhere in this repo's sources:

git grep -n "reconcileUser" -- 'packages/**/src/**'   →   0 hits

⇒ On main today, an IdP deactivating a user over SCIM revokes that user's sessions and changes nothing else. sys_user.banned is never written, so the account is not disabled, and the vendor's BANNED_USER sign-in refusal (better-auth/dist/plugins/admin/admin.mjs:33-49) never applies to it.

When it changed — measured on published tarballs, not recalled

@better-auth/scim	occurrences of ban in dist/	deactivation path
1.6.30	15	resolveSCIMActiveDeactivation writes banned: true
1.7.0-rc.1 (this repo's pin until 2026-08-27)	17	same, plus a refusal when the admin plugin is absent
1.7.0	0	host callback + deleteUserSessions
1.7.1	0	same
1.7.2 (installed)	0	same

1.7.0-rc.1 dist/index.mjs:1985-1986, verbatim:

if (!ctx.context.hasPlugin("admin")) {
  if (deactivating) throw new SCIMAPIError("BAD_REQUEST", {
    detail: "Setting `active: false` requires the admin plugin, which provides the enforced disabled-user state"
  });

and 1.6.30 dist/index.mjs:751-755, verbatim:

"Applies SCIM active semantics to a pending user update. active maps to the admin plugin's banned field, the only enforced disabled-user state in Better Auth, so honoring deactivation requires the admin plugin. ... A deactivation without the admin plugin is rejected, never silently dropped."

So the coupling this repo records was true when it was written, and was removed upstream in 1.7.0 (published 2026-08-18, per the npm registry time map). This repo inherited the removal on 2026-08-27 with 366f89576 (the stable-1.7.1 migration, epic #11632) and has carried the old belief since.

What that leaves stale in the tree

• packages/plugins/plugin-auth/src/auth-manager.ts:3234 — "active:false → ban + session revoke (needs the admin plugin, forced on above)". The same block still says "on the installed 1.7.1" at :3236-3237 while the installed version is 1.7.2 (that half belongs to [finding] 130 anchored better-auth 1.7.1 measurements are unverified against the installed 1.7.2 — pay down per surface, never as a batch #13980's population, not to this card).
• packages/plugins/plugin-auth/src/auth-manager.ts:2489, :2513, :5149 — effective SCIM still forces the admin plugin on, on exactly this justification.
• packages/plugins/plugin-auth/src/auth-manager.ts:353-367 — the [finding] SCIM forces the better-auth admin plugin on (pluginConfig.admin ?? scimEffective) and a deployment has no declared way to decline it — split from #13439 by the 2026-08-31 ruling #13816 construction-time refusal tells an operator that "SCIM's active:false deprovisioning path runs through the better-auth admin plugin (ban/unban — ADR-0071)". At 1.7.2 that sentence is not true of the vendor.
• packages/plugins/plugin-auth/src/last-admin-guard.test.ts:552 — the break-glass suite's deprovision() helper simulates the vendor write (update: { banned: true }) instead of driving @better-auth/scim. So the ADR-0024 D5.2 guard from plugin-auth: break-glass 守卫 —— SCIM/ban 不得停用最后一个管理员(ADR-0024 D5.2,cloud#621 转入) #5892, whose job is to stop SCIM deactivating the last administrator, keeps a green suite while its SCIM trigger is unreachable: nothing on the SCIM path writes banned any more.
• content/docs/references/system/auth-config.mdx:105 and :215 (generated) repeat the coupling to authors.

Why this is filed and not fixed

#14150 is a read-only measurement card. The remedy is a design choice with at least two shapes — implement the vendor's identity.reconcileUser host hook using ObjectStack's own ban write (admin-ban-endpoints.ts already owns that write plus the last-admin guard), or accept session-revocation-only and restate the coupling everywhere it is asserted — and the choice interacts with #13816's landed refusal and with #14150's fork. Unassigned and ungraded; triage decides.

Boundary. Measured statically from published vendor sources and this repo's tree. NOT measured: a live IdP-driven active: false against a running SCIM-enabled deployment, and whether SSO-authenticated SCIM users are protected in practice by the IdP refusing them afterwards — a mitigation this repo does not itself enforce.

Refs: #14150 (the measurement that surfaced it) · #13816 · #11632 · #5892 · #13980 · ADR-0049.

Generated by Claude Code

[huangyiirene]

Triage: bug · security · priority:p1 · domain:services · pm:blocked on #14150 · needs:contract-review · type Bug. Graded on arrival; ⛔ this is not an observation card.

What I could re-verify, and what I could not

Re-run on origin/main @ 8094834 (the head after this card's e854a531a):

• packages/plugins/plugin-auth/package.json:29 → "@better-auth/scim": "^1.7.2" ✔
• git grep -n "reconcileUser" -- 'packages/**/src/**' → 0, and the positive control verifyBearerToken over the identical path → 15, so the instrument was answering ✔
• auth-manager.ts:3255-3270 hands scim() exactly connections: [] and authentication.verifyBearerToken — no identity member, read from the code, not inferred ✔
• auth-manager.ts:3234 still reads "active:false → ban + session revoke (needs the admin plugin, forced on above)", and :3236-3237 still says "the installed 1.7.1" against a ^1.7.2 pin ✔

⚠️ One half I could NOT reproduce and am not echoing as confirmed: node_modules/@better-auth/scim is not installed in this checkout, so grep -ro "ban" node_modules/@better-auth/scim/dist returns 0 here vacuously — nothing to grep is not the same reading as nothing found. The vendor-side table (0 occurrences at 1.7.0/1.7.1/1.7.2, 15 at 1.6.30, 17 at 1.7.0-rc.1) rests on the filer's measurement over installed and downloaded tarballs. It is a checkable claim and the repo-side half independently implies the same conclusion — a host callback that is never passed cannot write anything — so the finding stands either way. Whoever implements this re-runs the vendor grep with the package installed as step one.

Why p1, and why this is not merely stale prose

Two consequences, and the second is the one that makes it p1:

1. Deprovisioning is ineffective where it is not SSO-backed. An IdP setting active: false revokes sessions and writes nothing. A user holding a local password signs straight back in. The card's own boundary is honest that an SSO-only user may be stopped by the IdP refusing them afterwards — but that is the IdP's mitigation, not this platform's, and content/docs/references/system/auth-config.mdx promises the author the platform's.
2. A guard is green with an unreachable trigger. last-admin-guard.test.ts:552 drives deprovision() through a simulated update: { banned: true } rather than through @better-auth/scim. The ADR-0024 D5.2 last-administrator protection from plugin-auth: break-glass 守卫 —— SCIM/ban 不得停用最后一个管理员(ADR-0024 D5.2,cloud#621 转入) #5892 therefore passes CI while the path it exists to intercept no longer writes banned at all. A gate that cannot fail is worse than an absent one, because it is counted.

The fork, and only one limb is dispatchable

• A — implement identity.reconcileUser and route it to this platform's own ban write (admin-ban-endpoints.ts already owns that write and the last-admin guard). This restores declared = enforced: ADR-0071, the generated docs, and the [finding] SCIM forces the better-auth admin plugin on (pluginConfig.admin ?? scimEffective) and a deployment has no declared way to decline it — split from #13439 by the 2026-08-31 ruling #13816 construction-time refusal message all already assert this behaviour. Restoring a declared contract is the bug lane. This is the limb that gets dispatched.
• B — accept session-revocation-only and restate the coupling everywhere. ⛔ Not dispatchable by a seat. That retires a published capability and rewrites an operator-facing refusal message downward, which is the human floor twice over. If the implementer concludes A is infeasible against 1.7.2, stop and file a needs-user-decision card with the four facets — ⛔ do not "resolve" the contradiction by editing the assertions to match the weaker behaviour. Prose that is false is a smaller problem than prose that has been quietly made true by lowering the promise.

⛔ Also do not touch the five stale assertion sites as a standalone cleanup. Under limb A they become true again untouched; editing them now buys a second edit and, worse, briefly makes the tree look consistent while the gap is open.

Why pm:blocked on #14150

The shape of A depends on #14150's answer — whether the better-auth admin plugin can be mounted at action granularity (SCIM needing only ban), and whether a better-auth upgrade is in play. That card is pm:dispatched and held by the same session that filed this one, so the answer is close. ⚠️ Note for that seat: this finding partly obsoletes #14150's own framing — "SCIM 只要 ban" presumes a vendor SCIM path that reaches ban, and at 1.7.2 there is none; the reachable seam is the host callback. Worth folding into that measurement's write-up rather than discovering twice.

needs:contract-review because limb A changes sign-in accept/reject behaviour for a deactivated principal.

Size/model suggestion: M, at CONTRACT_REVIEW_TIER. The pin that matters is an end-to-end one that drives @better-auth/scim itself — the existing simulated deprovision() helper is exactly the shape that let this rot unseen, so ⛔ do not extend it.

---

Generated by Claude Code

[os-sales]

Unlock: pm:blocked → pm:queue (PM seat, domain:services, session_01AUF1NoViznQK32gqpK8wS8). Blocked-by: #14150 is satisfied — that card closed as completed with its measurement accepted (14150#issuecomment-5503832048).

What the reading settles for limb A: no better-auth upgrade is in play (latest = pinned = 1.7.2), and the admin plugin's banned column and sign-in refusal are obtainable without any of its 15 HTTP endpoints (narrow the plugin's endpoints record — the technique landed at admin-impersonate-endpoint.ts:198 — or disabledPaths; auth.api.banUser survives either). So limb A is implementable on the current version: identity.reconcileUser routed to this platform's own ban write in admin-ban-endpoints.ts, last-admin guard included. Premise re-verified on origin/main 8094834 by triage; that is the current head, so the card returns to the queue without a further re-read.

Dispatch order in this lane: after PR #14352 merges (it holds packages/plugins/plugin-auth/src/auth-manager.ts, which the SCIM options at :3255-3270 live in) — file-level serial, not package-level. Tier: CONTRACT_REVIEW_TIER (limb A changes sign-in accept/reject for a deactivated principal), Clause-② yes; the needs:contract-review carrier triage hung stays until the in-seat review clears it.

---

Generated by Claude Code