deps(auth): move the better-auth family off the 1.7.0-rc.2 prerelease onto stable ^1.7.1 (#9869)

* deps(auth): move the better-auth family off 1.7.0-rc.2 onto the stable ^1.7.1 line

Stable 1.7.x has shipped: `npm view <pkg> dist-tags` reports latest 1.7.1 for
better-auth, @better-auth/core, oauth-provider, sso, the five adapters and
telemetry. The prerelease pin was the remediation for GHSA-p2fr-6hmx-4528 and
GHSA-j8v8-g9cx-5qf4 (patched only in >=1.7.0-beta.4), so it could not be dropped
until a stable line above that floor existed. It now does.

- pnpm-workspace.yaml overrides move to `^1.7.1`, with the selector bounds
  reshaped to the MAJOR boundary (`pkg@<2.0.0`) so a future advisory lift moves
  only the target — the shape the file's own header mandates. This retires the
  better-auth carve-out in the drift note.
- plugin-auth's direct declarations move to `^1.7.1` in lockstep (overrides do
  not ship with published packages; check:override-consistency holds them).
- @better-auth/scim stays at 1.7.0-rc.1. Measured against the published 1.7.1
  tarball, stable ships the rc.2 REWRITE — no scimProvider model, no
  generate-token endpoint, and all six new models present — so moving it is the
  ADR-0071 migration tracked by #3653, not this bump. rc.1 is above the advisory
  fix floor and its peer ranges accept the stable 1.7.1 core.

Refs #3002

* fix(auth): absorb the rc.2 → stable 1.7 vendor drift on the auth surface

Moving to stable 1.7.1 surfaced three pieces of upstream drift that the pinned
rc.2 did not have. All three were caught by the repo's own drift gates, and all
three are mechanical parity — no behaviour is authored here.

1. THE ACCOUNT ID FIELD FLIP-FLOPPED. `1.7.0-rc.2` renamed `account.accountId`
   → `providerAccountId`; stable 1.7.0/1.7.1 renamed it BACK to `accountId`,
   keeping the new required `issuer`. Measured on the installed 1.7.1:
   `getAuthTables({}).account.fields` = `issuer, accountId, providerId, userId,
   …` with no `providerAccountId` at all. Carrying the rc.2 spelling left
   `accountId` unmapped, so the adapter asked for a column of that name and
   EVERY sign-up answered 500 `Unknown field 'accountId' on object
   'sys_account'`. The `account_id` column is unchanged and no data moves.
   Fixed in the schema mapping, in the `createAccount` call in
   admin-user-endpoints, in the two mapping pin tests, and in the client's
   `/list-accounts` response type.

2. `@better-auth/oauth-provider` 1.7.1's `oauthClient` model writes three
   fields the platform object did not answer for: `applicationType` (the OIDC
   spelling of what rc.2 called `type` — mapped onto the EXISTING `type`
   column, so no data moves), plus genuinely new `clientDiscoveryId` and
   `clientCredentialsScopes`, now declared on `sys_oauth_application`. Without
   these, `POST /oauth2/register` 500s at the driver.

3. Two new endpoints are mounted publicly by the catch-all:
   `POST /oauth2/end-session` and `POST /oauth2/end-session/confirm` — the POST
   form of OIDC RP-initiated logout, whose GET counterpart was already
   ledgered. Added to BETTER_AUTH_MOUNTED_SURFACE with that rationale.

Also re-points the #5024 prerelease-pin probe at the state this leaves behind:
`@better-auth/scim` is the only prerelease pin left, so its follow-up ledger
names #3653 (the ADR-0071 migration) alone rather than a card this PR closes.

plugin-auth: 55 files, 1263 tests, all passing. tsc --noEmit clean.

Refs #3002

* chore(i18n): regenerate platform-objects bundles for the two new sys_oauth_application columns

Generated output, not hand-edited: node scripts/check-i18n-bundles.mjs --write.
`pnpm check:i18n` is green again (9 packages, all bundles in sync).

Refs #3002

* fix(showcase): the demo-persona seeder writes the stable 1.7 account id key

Second `internalAdapter.createAccount` call site carrying the rc.2
`providerAccountId` spelling — found by the dogfood suite, not by grep:
`showcase-demo-personas-loginable.dogfood.test.ts` failed with

  phone.demo@example.com holds a credential account: expected undefined to be truthy
  verify signIn failed: 401 {"code":"INVALID_EMAIL_OR_PASSWORD"}

The account row was written with no account id, so better-auth's
`findAccountByKey({ issuer, accountId })` could not see it and both demo
personas were silently un-loginable — exactly the failure mode #9308 fixture 1
exists to prevent, and exactly the shape its own comment warns about (a
misleading "User not found" pointing at the sys_user row rather than the
account). The admin persona was unaffected, which is why only the persona test
caught it.

Also adds the changeset for the family bump, the drift it absorbs, and the one
consumer-visible rename (`@objectstack/client`'s `/list-accounts` response
type), and lowers plugin-auth's TEST_DEBT ceiling 111 → 110 to the number this
branch now measures, as `check:type-check-debt` prescribes.

Verified: showcase-demo-personas-loginable dogfood 4/4 pass; the auth-path
dogfood set 57/57; app-showcase 337 tests + tsc clean.

Refs #3002

* docs(auth): the account-mapping section names the stable 1.7 field, with the flip-flop stated

content/docs/permissions/authentication.mdx documented the mapping as
`providerAccountId: 'account_id'` and told the reader that is "the field
formerly called accountId". On stable 1.7 that is backwards, and a reader
following it writes exactly the mapping that answers 500 on every sign-up.

The field name moved twice inside the 1.7 line — rc.2 renamed
`accountId` → `providerAccountId`, stable 1.7.0 renamed it back — so the
correction carries a callout saying so rather than silently swapping the word:
the next reader arriving from an rc-era note needs to know which way it went.

content/docs/releases/ is left alone by rule; its v15/v17 entries are accurate
records of what those releases did.

Refs #3002

Author: os-warren

.changeset/better-auth-family-stable-1-7.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/plugin-auth": patch
+"@objectstack/platform-objects": patch
+"@objectstack/client": patch
+---
+
+deps(auth): the better-auth family moves off the `1.7.0-rc.2` prerelease onto stable `^1.7.1` (#3002)
+
+`@objectstack/plugin-auth` shipped with **exact pins on a release candidate** —
+`better-auth`, `@better-auth/core`, `@better-auth/oauth-provider` and
+`@better-auth/sso` all at `1.7.0-rc.2`. That pin was never housekeeping debt: it was
+the remediation for **GHSA-p2fr-6hmx-4528** (`@better-auth/oauth-provider`) and
+**GHSA-j8v8-g9cx-5qf4** (`@better-auth/scim`, high — account/provider takeover), both
+patched only in `>=1.7.0-beta.4`, so there was no stable line to move to. Upstream has
+now shipped one: `npm view <pkg> dist-tags` reports `latest: 1.7.1` for every family
+member. The declarations become `^1.7.1`, which is what a downstream
+`npx create-objectstack` install now resolves.
+
+**`@better-auth/scim` deliberately stays at `1.7.0-rc.1`.** Measured against the
+published stable tarball rather than assumed: `@better-auth/scim@1.7.1` ships the rc.2
+**rewrite** — no `scimProvider` model, no generate-token endpoint, and six replacement
+models (`scimUser`, `scimGroup`, `scimGroupMember`, `scimSubject`,
+`scimConnectionBinding`, `scimIdentityTombstone`). Adopting it is a feature migration
+(ADR-0071, tracked separately), not a version bump. The hold stays security-clean: rc.1
+is above the advisory's fix floor, `pnpm audit --audit-level=high` is green, and rc.1's
+peer ranges accept the stable 1.7.1 core the rest of the family resolves to.
+
+**Three pieces of upstream drift are absorbed here, and one of them was a live
+sign-in outage waiting to happen.**
+
+`1.7.0-rc.2` renamed the account model's `accountId` field to `providerAccountId`;
+**stable 1.7.0/1.7.1 renamed it back to `accountId`**, keeping the new required
+`issuer`. Carrying the rc.2 spelling into the stable line left the field unmapped, so
+better-auth's adapter asked for a column named `accountId` and **every sign-up answered
+500** — `Unknown field 'accountId' on object 'sys_account'`. The `account_id` column
+itself never changed and no data moves; only the camelCase key does. The same rename
+reaches `@objectstack/client`: `auth.accounts.list()` (better-auth's `/list-accounts`)
+returns `accountId`, and its declared response type said `providerAccountId`. If you
+read that field off the client's typed response, rename it.
+
+`@better-auth/oauth-provider` 1.7.1's client model writes three fields the platform
+object did not answer for. `applicationType` is the OIDC spelling of what rc.2 called
+`type`, so it maps onto the **existing** `type` column and no data moves;
+`clientDiscoveryId` and `clientCredentialsScopes` are genuinely new and are now
+declared on `sys_oauth_application` as `client_discovery_id` and
+`client_credentials_scopes`. Without them, dynamic client registration
+(`POST /oauth2/register`) fails at the driver.
+
+Two endpoints are newly mounted by the auth catch-all and are now ledgered:
+`POST /oauth2/end-session` and `POST /oauth2/end-session/confirm` — the POST form of
+OIDC RP-initiated logout, whose `GET` counterpart was already published.
+
+**Nothing here needs an action on upgrade.** The new columns are additive and optional,
+and the field rename is internal to how the plugin talks to better-auth — with the one
+exception of the `@objectstack/client` response type named above.

content/docs/permissions/authentication.mdx

@@ -1048,17 +1048,26 @@ The plugin bridges this gap using better-auth's official **`modelName` / `fields
 // Declared in the betterAuth() config via AUTH_*_CONFIG constants:
 user:         { modelName: 'sys_user',         fields: { emailVerified: 'email_verified', … } },
 session:      { modelName: 'sys_session',      fields: { userId: 'user_id', expiresAt: 'expires_at', … } },
-account:      { modelName: 'sys_account',      fields: { providerId: 'provider_id', issuer: 'issuer', providerAccountId: 'account_id', … } },
+account:      { modelName: 'sys_account',      fields: { providerId: 'provider_id', issuer: 'issuer', accountId: 'account_id', … } },
 verification: { modelName: 'sys_verification', fields: { expiresAt: 'expires_at', … } },
 ```
 
-better-auth 1.7 identifies an account by `(issuer, providerAccountId)` — `providerAccountId` is
-the field formerly called `accountId` (same `account_id` column) and `issuer` names the authority
-that vouched for it: an OIDC `iss` for federated logins, or a synthetic `local:credential` /
+better-auth 1.7 identifies an account by `(issuer, accountId)`. `issuer` names the authority
+that vouched for the id: an OIDC `iss` for federated logins, or a synthetic `local:credential` /
 `local:oauth:<providerId>` for providers that carry none. Rows written before 1.7 have no issuer,
 so the auth plugin stamps them once at boot; accounts from a federated IdP that is no longer
 registered cannot be derived and are reported in the boot log instead of guessed.
 
+<Callout type="warn">
+The account id field's NAME changed twice inside the 1.7 line, so read it off the version you
+run rather than off an older note. The `1.7.0-rc.2` pre-release renamed `accountId` →
+`providerAccountId`; the stable `1.7.0` / `1.7.1` releases renamed it **back to `accountId`**,
+keeping the new `issuer`. The `account_id` column is the same throughout — only the camelCase
+key moved. On stable 1.7 the mapping above, and any `internalAdapter.createAccount({ …,
+accountId })` call, must use `accountId`; the rc.2 spelling leaves the field unmapped and every
+sign-up answers 500 `Unknown field 'accountId' on object 'sys_account'`.
+</Callout>
+
 The ObjectQL adapter factory (`createObjectQLAdapterFactory`) then uses better-auth's `createAdapterFactory`
 which automatically transforms all data and where-clauses using these mappings — no manual
 camelCase ↔ snake_case conversion is needed in the adapter.

examples/app-showcase/src/security/demo-personas.ts

@@ -40,7 +40,7 @@
  * distinct people, a submitter who is not an approver, an out-of-office
  * delegation decided under the delegate's own identity — was stuck on it, and
  * each rediscovered the same non-obvious cause: a password hash is not enough.
- * better-auth 1.7 keys accounts on `(issuer, providerAccountId)`, so a
+ * better-auth 1.7 keys accounts on `(issuer, accountId)`, so a
  * credential row whose `issuer` is not the local credential issuer is INVISIBLE
  * to sign-in, which then fails `INVALID_EMAIL_OR_PASSWORD` behind a misleading
  * "User not found" — pointing at the row, which is fine, instead of at the

examples/app-showcase/src/security/seed-approval-demo.ts

@@ -92,7 +92,13 @@ interface AuthContextLike {
       userId: string;
       providerId: string;
       issuer: string;
-      providerAccountId: string;
+      /**
+       * The STABLE better-auth 1.7 spelling. `1.7.0-rc.2` briefly called this
+       * `providerAccountId` and stable 1.7.0 renamed it back (#3002) — under
+       * the rc.2 spelling the account row is written with no account id and
+       * the persona silently stays un-loginable.
+       */
+      accountId: string;
       password: string;
     }) => Promise<unknown>;
   };
@@ -176,7 +182,7 @@ async function assignPositions(
  *
  * ## Why this is read and not written
  *
- * better-auth 1.7 keys account identity on `(issuer, providerAccountId)`:
+ * better-auth 1.7 keys account identity on `(issuer, accountId)`:
  * `findAccountByKey` looks a credential up under the issuer better-auth mints
  * for itself, so a row carrying any other value — or none — is INVISIBLE and
  * sign-in fails `INVALID_EMAIL_OR_PASSWORD` behind a "User not found" warn that
@@ -245,7 +251,7 @@ async function ensureCredentialAccount(
       userId,
       providerId: 'credential',
       issuer,
-      providerAccountId: userId,
+      accountId: userId,
       password: hashed,
     });
     ctx.logger?.info?.('[showcase] approval-demo persona is now loginable', { userId });

packages/client/src/index.ts

@@ -2788,10 +2788,14 @@ export class ObjectStackClient {
         return { accounts: accounts as Array<{
           id: string;
           providerId: string;
-          /** Authority that vouched for `providerAccountId` — an OIDC issuer, or `local:…`. */
+          /** Authority that vouched for `accountId` — an OIDC issuer, or `local:…`. */
           issuer: string;
-          /** The user's id at the provider — better-auth 1.7 renamed this from `accountId`. */
-          providerAccountId: string;
+          /**
+           * The user's id at the provider. `1.7.0-rc.2` briefly published this
+           * as `providerAccountId`; stable 1.7 answers with `accountId` again
+           * (#3002), which is what this route returns today.
+           */
+          accountId: string;
           createdAt?: string;
           updatedAt?: string;
         }> };

packages/platform-objects/src/apps/translations/en.objects.generated.ts

@@ -1228,6 +1228,10 @@ export const enObjects: NonNullable<TranslationData['objects']> = {
         label: "Client ID",
         help: "Public OAuth client identifier"
       },
+      client_discovery_id: {
+        label: "Client Discovery ID",
+        help: "Opaque identifier the provider uses to look this client up on the discovery path, kept apart from the public `client_id`"
+      },
       client_secret: {
         label: "Client Secret",
         help: "OAuth client secret — stored as a SHA-256 digest, never plaintext (`@better-auth/oauth-provider`'s `storeClientSecret`, which defaults to hashed whenever the jwt plugin is enabled; wired in plugin-auth's `AuthManager.buildPluginList()`, oidcProvider branch). Shown once at registration."
@@ -1272,6 +1276,10 @@ export const enObjects: NonNullable<TranslationData['objects']> = {
         label: "Allowed Scopes",
         help: "JSON-serialized list of scopes the client may request"
       },
+      client_credentials_scopes: {
+        label: "Client-Credentials Scopes",
+        help: "JSON-serialized list of scopes the client may request on the client_credentials grant, where there is no user to consent — kept apart from `scopes`, which governs user-delegated grants"
+      },
       subject_type: {
         label: "Subject Type",
         help: "OIDC subject type (e.g. public, pairwise)"

packages/platform-objects/src/apps/translations/es-ES.objects.generated.ts

@@ -1228,6 +1228,10 @@ export const esESObjects: NonNullable<TranslationData['objects']> = {
         label: "ID de cliente",
         help: "Identificador público del cliente OAuth."
       },
+      client_discovery_id: {
+        label: "Client Discovery ID",
+        help: "Opaque identifier the provider uses to look this client up on the discovery path, kept apart from the public `client_id`"
+      },
       client_secret: {
         label: "Secreto de cliente",
         help: "Secreto del cliente OAuth (con hash/cifrado en reposo)."
@@ -1272,6 +1276,10 @@ export const esESObjects: NonNullable<TranslationData['objects']> = {
         label: "Ámbitos permitidos",
         help: "Lista serializada en JSON de ámbitos que el cliente puede solicitar."
       },
+      client_credentials_scopes: {
+        label: "Client-Credentials Scopes",
+        help: "JSON-serialized list of scopes the client may request on the client_credentials grant, where there is no user to consent — kept apart from `scopes`, which governs user-delegated grants"
+      },
       subject_type: {
         label: "Tipo de sujeto",
         help: "Tipo de sujeto OIDC (p. ej. public, pairwise)."

packages/platform-objects/src/apps/translations/ja-JP.objects.generated.ts

@@ -1228,6 +1228,10 @@ export const jaJPObjects: NonNullable<TranslationData['objects']> = {
         label: "クライアント ID",
         help: "公開 OAuth クライアント識別子"
       },
+      client_discovery_id: {
+        label: "Client Discovery ID",
+        help: "Opaque identifier the provider uses to look this client up on the discovery path, kept apart from the public `client_id`"
+      },
       client_secret: {
         label: "クライアントシークレット",
         help: "OAuth クライアントシークレット（保存時にハッシュ/暗号化済み）"
@@ -1272,6 +1276,10 @@ export const jaJPObjects: NonNullable<TranslationData['objects']> = {
         label: "許可スコープ",
         help: "クライアントがリクエスト可能なスコープの JSON シリアライズリスト"
       },
+      client_credentials_scopes: {
+        label: "Client-Credentials Scopes",
+        help: "JSON-serialized list of scopes the client may request on the client_credentials grant, where there is no user to consent — kept apart from `scopes`, which governs user-delegated grants"
+      },
       subject_type: {
         label: "サブジェクトタイプ",
         help: "OIDC サブジェクトタイプ（例: public、pairwise）"

packages/platform-objects/src/apps/translations/zh-CN.objects.generated.ts

@@ -1228,6 +1228,10 @@ export const zhCNObjects: NonNullable<TranslationData['objects']> = {
         label: "客户端 ID",
         help: "公开的 OAuth 客户端标识"
       },
+      client_discovery_id: {
+        label: "Client Discovery ID",
+        help: "Opaque identifier the provider uses to look this client up on the discovery path, kept apart from the public `client_id`"
+      },
       client_secret: {
         label: "客户端密钥",
         help: "OAuth 客户端密钥（静态存储时会哈希/加密）"
@@ -1272,6 +1276,10 @@ export const zhCNObjects: NonNullable<TranslationData['objects']> = {
         label: "允许的范围",
         help: "客户端可申请的 scopes 的 JSON 序列化列表"
       },
+      client_credentials_scopes: {
+        label: "Client-Credentials Scopes",
+        help: "JSON-serialized list of scopes the client may request on the client_credentials grant, where there is no user to consent — kept apart from `scopes`, which governs user-delegated grants"
+      },
       subject_type: {
         label: "主体类型",
         help: "OIDC 主体类型（例如 public、pairwise）"

packages/platform-objects/src/identity/sys-account.object.ts

@@ -35,7 +35,7 @@ export const SysAccount = ObjectSchema.create({
   // this, where `accountId` is the account ROW id (better-auth 1.7 narrowed
   // the body from the old `{ providerId, accountId }` pair, and `accountId`
   // no longer means the provider's id for the user — that field is now
-  // `providerAccountId`). The form is locked to the row's values so it acts
+  // `accountId`). The form is locked to the row's values so it acts
   // as a one-click confirmation rather than a free-form edit.
   //
   // `link_social` is the self-service counterpart — a toolbar action
@@ -306,7 +306,7 @@ export const SysAccount = ObjectSchema.create({
   indexes: [
     { fields: ['user_id'], unique: false },
     { fields: ['provider_id', 'account_id'], unique: true },
-    // better-auth 1.7 resolves accounts by (issuer, providerAccountId) and
+    // better-auth 1.7 resolves accounts by (issuer, accountId) and
     // declares that pair unique on its own `account` table — mirror it here so
     // the physical table enforces the same identity key the auth code assumes.
     { fields: ['issuer', 'account_id'], unique: true },