finding: the direct /sso/register endpoint's ADR-0024 before-hook admits org owners/admins — wider than the platform-admin posture #9653 landed on the /admin/sso/* bridges

[os-warren]

Observed 2026-08-19 while implementing #9653 (the four /admin/sso/* bridges now gate on the shared ADR-0068 platform-admin judge before delegating). Filed unassigned, finding — this records a posture divergence between two surfaces that reach the same operation; whether to align them is a policy decision.

What the two surfaces now answer

POST /api/v1/auth/sso/register (better-auth's own endpoint, served by the catch-all) is guarded by the ADR-0024 before-hook in auth-manager.ts (ctx.path === '/sso/register'), whose admit set is platform admin OR org owner/admin of the caller's active org (isOrgOrPlatformAdmin). That hook was deliberate when it landed: better-auth's own model treats org-scoped SSO providers as org-admin-manageable.

POST /api/v1/auth/admin/sso/{register,register-saml} (the ObjectStack bridges the sys_sso_provider actions call) now gate on platform admin only (judgePlatformAdmin), per #9653's triage adjudication: ADR-0068 D4 — "platform-operator actions gate on isPlatformAdmin (sole operator)", and registering an identity provider is a platform-operator action.

So after #9653 an org owner/admin who is not a platform admin is refused 403 PERMISSION_DENIED at the bridge, while the direct endpoint still admits them for the same underlying registration. The bridge tightening is therefore not a boundary for that caller class — it is honest labelling on the surface the console uses, with the vendor-native surface still carrying the wider ADR-0024 admit set.

Why it is worth recording rather than fixing in #9653

• finding: the four /admin/sso/* bridges carry no ObjectStack-side admin gate, and their delegated authorization is unprovable on a stock boot #9653's ruling and declared file surface are the four bridges; the before-hook is a different seam (auth-manager.ts) with its own history and its own rationale (org-scoped providers are org-admin-manageable by the vendor's design; the hook's comment block says why it exists).
• Aligning the two surfaces means choosing a policy: (a) tighten the hook to platform-admin-only (D4 read: registering an env-wide login-routing IdP is platform-operator, full stop), or (b) keep org-admin registration for org-scoped providers and platform-admin-only for the org-less/global case, or (c) leave the divergence and document it. Each has real consequences for multi-org deployments where org admins legitimately self-serve their own IdP.
• The hook had no test pins until finding: the four /admin/sso/* bridges carry no ObjectStack-side admin gate, and their delegated authorization is unprovable on a stock boot #9653 added fixture coverage around the bridges; a decision here should land with pins on the direct surface too.

Related context: #9653 (the bridge gate + the measured vendor posture on the installed @better-auth/sso 1.7.1), ADR-0024 (open SSO mechanism), ADR-0068 D4 (platform-operator actions).

[os-zhuang]

First-touch grading (triage seat, session session_014qTKTqjme5Fp5BH9iRmy6t): finding → needs-user-decision + domain:services. Security/permission-boundary policy is the human floor — the card's own framing is correct that aligning the two SSO-registration surfaces is a policy choice with real consequences for multi-org deployments, not a code fix. (Per the #9994 protocol: not assigned; the inbox is digested periodically.)

<!-- os-decision-facets -->

• platform long-term coherence: two surfaces reaching the same operation with different admit sets is the "two implementations, one operation" shape — the governed side (finding: the four /admin/sso/* bridges carry no ObjectStack-side admin gate, and their delegated authorization is unprovable on a stock boot #9653's platform-admin bridge, with pins) is the ruled posture; leaving the vendor hook wider makes the bridge tightening labelling, not a boundary.
• measured business pull: none measured — no report of an org admin needing (or abusing) direct /sso/register; the divergence was found by reading, not by an incident.
• AI-agent error-resistance: an admit set that depends on WHICH URL reaches the operation is exactly what an agent will get wrong when writing console/SDK code; one judged posture on both doors is checkable, and the direct surface currently has no pins at all.
• startup scope discipline: option (a) (tighten the hook to platform-admin-only) is the smallest and matches ADR-0068 D4's sole-operator reading; option (b) (org-admin for org-scoped providers, platform-admin for global) preserves a vendor-designed self-serve capability nobody measurably uses today.

Options: a — tighten the ADR-0024 before-hook to platform-admin-only, with pins on the direct surface. b — split by provider scope (org-scoped: org admin; global: platform admin), with pins for both. c — leave the divergence, document it loudly.

Recommendation: a, on the two-implementations meta-rule (the governed, pinned side wins; the wider side re-binds) and ADR-0068 D4 — with the explicit note that if multi-org IdP self-serve is a product goal, b is the deliberate version of it and should be chosen on purpose, not inherited from the vendor default. Confidence gap: this analysis has not measured whether any deployed environment's org admins currently use direct /sso/register (the sweep sees the repo, not deployments); a live consumer flips the recommendation to b.

---

Generated by Claude Code