[security] `sys_sso_provider.oidc_config` carries the OIDC `clientSecret` in a cleartext JSON textarea, by its own field description

[huangyiirene]

Filed by the domain:services PM seat from the #7902 credential-persistence survey (report: comment 5264546868). Unassigned, no pm:queue, no domain:* — see routing note. For triage to grade and route.

The finding

sys_sso_provider.oidc_config is a textarea whose own field description states what it holds:

"JSON: clientId, clientSecret, endpoints, scopes, mapping, pkce"

— packages/platform-objects/src/identity/sys-sso-provider.object.ts:267-272. Read back by the better-auth SSO plugin.

This is shape ① from the survey: a credential inside a serialized JSON blob, on an object reachable through the ordinary data API (sys_sso_provider declares apiMethods: ['get','list']).

An OIDC clientSecret is the credential that authenticates this platform to the identity provider. Anyone who can read the row can impersonate the platform's OIDC client against that IdP.

What makes this one distinctive

Unlike the other ① hits, nothing here is hidden or accidental. The blob is doing exactly what its description says. There is no drift between declaration and behaviour to point at — which means:

• the "declared ≠ enforced" framing does not apply; and
• fixing it is not a repair, it is a decision to change a shipped storage shape, with migration for existing rows.

That is why it is filed as a finding for grading rather than a defect to dispatch. The card that takes it up has to choose a shape first, and that choice has an owner beyond this lane (below).

Shape of a fix, if wanted (⛔ not decided here)

Same fork as #7986, and for the same reason — a blob with mixed sensitivity:

• pull only clientSecret into a Field.secret()-backed column, leaving the rest of the config in the blob (needs a shape change to what authors write);
• move the whole oidc_config behind Field.secret() (simple, but the non-secret half becomes unreadable to the admin UI that legitimately renders endpoints/scopes/mapping);
• redact on read (leaves cleartext at rest, which is the property the survey is about).

⚠️ better-auth owns the writes to this object — the same constraint that makes #7987 (sys_account OAuth tokens) hard. Any shape that routes the write through the engine's encrypt-on-write path has to sit between better-auth and its own adapter. That constraint is the first thing a card should measure, not the last.

Explicitly NOT claimed

• No leak is demonstrated. Reachable-cleartext finding; permissions on sys_sso_provider in a shipped deployment were not evaluated.
• Not an ADR-0100 case. Field.password() has zero occurrences repo-wide; this is a textarea, not a password-typed field.
• No regression. This predates every credential change landed today and was not touched by PR fix(webhooks): stop storing the subscriber signing secret in cleartext (#7799) #7901.

Routing note — why no domain:*

The column is declared in packages/platform-objects (domain:metadata); the consumer is the better-auth SSO plugin under plugin-auth (domain:identity); a Field.secret() route touches the objectql machinery (domain:engine-core). Which lane owns it depends on the shape chosen. Flagged rather than guessed, per the anchoring rule — the label is the domain of the package the fix lands in, never the domain of where it was found.

Evidence

Measured 2026-08-12 by the dev on #7902 (read-only survey, pr: null). Full 26-surface verdict table, including the reverse-checks that validate the clean verdicts, in comment 5264546868 on #7902.

Source

Split out of #7902 (survey item ①-e). Sibling cards from the same survey: #7986 (webhook headers), #7987 (sys_account OAuth tokens), #7990 (sys_metadata as a general cleartext sink).

[hotlong]

Triage (findings round): graded — escalated to needs-user-decision, routed domain:metadata (the column is declared in packages/platform-objects; the write-path constraint below may move the landing at split time), type Task.

Why this is a maintainer decision and not a dispatch: the card is explicit that nothing here is drift — the blob does what its description says, so a fix is a decision to change a shipped storage shape, with migration for existing rows. That is the maintainer floor (existing-data migration shape), same as the sibling #8103.

Four-lens block (decision card face):

1. Platform long-term coherence: pulling clientSecret into a Field.secret()-backed column converges on the platform's single credential-storage mechanism (the direction every card in the finding: survey — which other config objects still keep credentials in a JSON blob column, now that resolveSecretField() makes the Field.secret() channel readable #7902 family has moved); whole-blob encryption forks admin-UI readability; redact-on-read leaves cleartext at rest — the very property the survey measures.
2. Measured business pull: an OIDC clientSecret authenticates the platform itself to the IdP; sys_sso_provider declares apiMethods: ['get','list'], so reachability is real. No demonstrated leak, but SSO config is a first-thing-enterprise-customers-touch surface.
3. AI-agent error-resistance: a schema-named secret column (closed, publish-time-enforced) beats prose in a field description that an AI author will happily replicate into new objects. The current shape teaches by bad example.
4. Startup scope discipline: narrowest viable = split only clientSecret out of the blob + migration for existing rows; ⛔ no general "encrypt all JSON configs" program.

Recommendation: split clientSecret into a Field.secret() column (option 1), with the migration story written the same way #8103's decision resolves — the two cards should be decided together; they are the same shape one object apart. Precondition the decision names for whichever card implements: better-auth owns the writes to this object (same constraint as #7987) — the encrypt-on-write seam must sit between better-auth and its adapter, and measuring that seam is the implementing card's first task.

---

Generated by Claude Code

[hotlong]

Finding-grading round note (state unchanged — needs-user-decision + domain:metadata stand): one fact the decision should lead with. The same object file contradicts itself: the register-action helpText (sys-sso-provider.object.ts:99) says the client secret is "stored encrypted by better-auth", while the column description at :270 documents cleartext JSON (clientId, clientSecret, endpoints, scopes, mapping, pkce) on an API-readable column (apiMethods: ['get','list'], :313). Cleartext-at-rest is currently asserted from a description, never measured on a row — first step of whatever gets decided here: write a provider row and read it back. If better-auth already encrypts, this collapses to a docs fix plus the apiMethods narrowing.

---

Generated by Claude Code