fix(auth): make the SSO-provider registration form produce a usable IdP (ADR-0024 / cloud#551)

[os-zhuang]

Why

Follow-up to the cloud#551 SSO work (#2363 admin-gate, #2370 public-IdP trust). The open-source sys_sso_provider registration form was broken: its register_sso_provider action posts FLAT fields to @better-auth/sso's /sso/register, which expects the OIDC fields NESTED under oidcConfig. Top-level clientId/clientSecret get Zod-stripped → the form silently persists an oidc_config = null provider that returns "Invalid SSO provider" on login. So an admin could not actually configure a working IdP through the UI.

What

• plugin-auth: a shared runRegisterSsoProviderFromForm helper reshapes the flat form body into the nested shape and re-dispatches it through the real /sso/register (so the admin gate, the public-routable trustedOrigins allowance, discovery hydration, and secret handling all still run — zero logic duplicated). Exposed via a new /admin/sso/register bridge on the host AuthPlugin. The cloud per-environment runtime mounts the same helper in its AuthProxyPlugin (separate cloud PR) — mirrors how set-initial-password stays in lockstep across the two mount points.
• platform-objects: register_sso_provider retargets to /api/v1/auth/admin/sso/register and gains discoveryEndpoint, scopes, and attribute-mapping (mapId/mapEmail/mapName) fields.

This keeps runtime self-service IdP registration in the OSS edition — the open mechanism — rather than gating the config UI behind a paid tier.

Verification (browser E2E, local prod-like stack)

• Admin registers an external OIDC IdP from the flat form (/admin/sso/register) → 200; the provider has a populated oidcConfig (sign-in/sso returns a real authorize URL — was oidc_config:null → "Invalid SSO provider").
• A federated user logs in through the form-registered provider → JIT user alice@acme.example.com; list-accounts → providerId = the form-registered IdP.
• Regression: a non-admin registering via the bridge is rejected 403 (the admin gate fires through the re-dispatch); the route is mounted in the env runtime (was 404 — host-only AuthPlugin routes don't reach the env).

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
spec	Ready	Preview, Comment	Jun 27, 2026 3:45pm

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/platform-objects, @objectstack/plugin-auth.

11 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/concepts/implementation-status.mdx (via @objectstack/plugin-auth)
• content/docs/concepts/packages.mdx (via @objectstack/platform-objects, @objectstack/plugin-auth)
• content/docs/concepts/setup-app.mdx (via @objectstack/platform-objects)
• content/docs/getting-started/cli.mdx (via @objectstack/plugin-auth)
• content/docs/guides/auth-sso.mdx (via @objectstack/plugin-auth)
• content/docs/guides/authentication.mdx (via @objectstack/plugin-auth)
• content/docs/guides/kernel-services.mdx (via @objectstack/plugin-auth)
• content/docs/guides/packages.mdx (via @objectstack/platform-objects, @objectstack/plugin-auth)
• content/docs/guides/plugins.mdx (via @objectstack/plugin-auth)
• content/docs/guides/production-readiness.mdx (via @objectstack/plugin-auth)
• content/docs/releases/v9.mdx (via @objectstack/plugin-auth)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.