feat(auth): surface features.sso in public /auth/config

[os-zhuang]

Problem

The console login page renders a "Sign in with SSO" button unconditionally. On a deployment where enterprise SSO isn't wired (default for self-hosted / os dev), the /sign-in/sso route isn't mounted, so the button is a dead end that only reveals "No SSO provider is configured for this email domain." at click time.

Root cause on the server side: getPublicConfig() (the /auth/config payload the SPA reads) advertised every other capability flag — oidcProvider, twoFactor, multiOrgEnabled, deviceAuthorization, … — but omitted enterprise SSO, even though the manager already computes whether @better-auth/sso is wired (OS_SSO_ENABLED / plugins.sso). The login UI had no signal to gate on.

Fix

Two layers, so the advertised capability matches reality at both granularities:

1. Coarse (sync, cheap) — getPublicConfig().features.sso now reports whether the plugin is wired, resolved with the EXACT logic that decides whether it's mounted in buildPlugins() (factored into a private isSsoWired()). This honours the invariant the existing comment already demands: "the /auth/config response MUST match what's actually wired, otherwise the frontend will render UI for endpoints that 404."

2. Precise (async, at the route) — the /auth/config handler refines that flag to usable via the new AuthManager.isSsoUsable(): wired AND at least one sys_sso_provider row exists. This also hides the button when SSO is enabled but no IdP is configured yet. It only queries when wired, and fails open to the wired flag on any introspection error (no data engine, query throws) so the login config never 500s. Applied in both the plugin-auth route and the hono adapter /config path (the latter guarded as a no-op against an older auth service).

Per-email domain→IdP matching still happens at /sign-in/sso; isSsoUsable() answers the coarser "is there any point showing the button at all".

Tests

auth-manager.test.ts:

• features.sso (coarse): default-off, on-via-plugins.sso, OS_SSO_ENABLED env override.
• isSsoUsable() (precise): not-wired (skips query), zero-providers → false, ≥1 provider → true, no-engine fail-open, query-throws fail-open.

95 plugin-auth tests green, hono suite green (67), tsc --noEmit clean on index.ts (3 pre-existing hono.test.ts context-typing errors are unrelated). Browser end-to-end verification of the live /auth/config + login page done alongside the objectui PR.

Pairs with

Client-side consumer that hides the button: objectstack-ai/objectui#2006

🤖 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 25, 2026 4:11pm

[github-actions]

📓 Docs Drift Check

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

10 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/plugin-auth)
• 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 packages/adapters, @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.