fix: OIDC discovery trusted origins for IdP registration

[joeyorlando]

What changed

This narrows a recent Better Auth trusted-origin workaround to include the admin identity-provider create flow in addition to the existing /sso/register path and internal auth.api registration calls.

Why it changed

There was a report of Untrusted OIDC discovery URL while reinstalling a Generic OIDC provider in an environment even though the Okta/Archestraconfiguration matched a working setup. The root cause is that Better Auth can evaluate OIDC discovery trust against the outer /api/identity-providers request during provider creation, while our existing workaround only widened trust for /sso/register and request-less internal calls.

Impact

Generic OIDC provider creation and reinstall flows now allow Better Auth's discovery validation to proceed for the admin IdP registration request without widening trusted origins for normal auth traffic.

[claude]

Claude finished @joeyorlando's task in 2m 22s —— View job

---

PR Review: OIDC discovery trusted origins for IdP registration

• Read repo context (CLAUDE.md, routes, model layer)
• Read better-auth.ts and the trusted-origins helper
• Read new test case in better-auth.test.ts
• Verify /api/identity-providers is the correct Fastify route
• Confirm update/delete flows don't need the same workaround
• Post review feedback

---

Summary

The fix is correct, minimal, and well-scoped. It addresses a real edge case where Better Auth's trustedOrigins callback is invoked with the outer HTTP request (the admin-facing POST /api/identity-providers) rather than with an internal request-less call, so the existing /sso/register + !request checks alone weren't enough to let OIDC discovery pass during provider reinstall.

The rename from shouldTrustAllOriginsForSsoRegistration to shouldTrustAllOriginsForIdentityProviderRegistration correctly reflects the new broader scope, and the updated JSDoc captures the nuance.

Correctness

• IDENTITY_PROVIDERS_API_PREFIX is defined as "/api/identity-providers" in platform/backend/src/constants.ts:4, matching the hard-coded path in shouldTrustAllOriginsForIdentityProviderRegistration at platform/backend/src/auth/better-auth.ts:459.
• The POST handler at platform/backend/src/routes/identity-provider.ee.ts:113 is the only mutating route that actually re-enters Better Auth (via IdentityProviderModel.create → auth.api.registerSSOProvider at platform/backend/src/models/identity-provider.ee.ts:598). update/delete go straight to Drizzle, so no workaround is needed there. Good call not widening the PUT path.
• Fastify is constructed without ignoreTrailingSlash (platform/backend/src/server.ts:250), so a client can't hit /api/identity-providers/ and still reach the route — strict equality (pathname === "/api/identity-providers") is safe and matches Fastify routing behavior.
• The new URL(request.url) guard with try/catch is preserved, so malformed URLs still fall back to "not trusted" rather than throwing.

Tests

The new test at platform/backend/src/auth/better-auth.test.ts:348 directly exercises the new branch and matches the shape of the existing /sso/register test. The three-test coverage (internal call, /sso/register, /api/identity-providers, plus the negative case) is solid.

One small thought: you might consider adding a negative assertion for a near-miss like POST /api/identity-providers/abc123 (the PUT path) to lock in that updates don't accidentally get wildcard trust if someone later refactors the check to startsWith or includes. Not blocking — the existing "keeps regular auth requests" test already covers the general non-match case.

Nits (non-blocking)

• platform/backend/src/auth/better-auth.ts:408-410 — the comment phrasing "In practice, the same flow can also inherit the outer /api/identity-providers request" is accurate but a bit subtle. A one-line mention that Better Auth reuses the ambient Fastify request context when the IdP model forwards headers into auth.api.registerSSOProvider would help a future reader understand why the outer URL bleeds through.
• Consider hoisting the literal "/api/identity-providers" to reference IDENTITY_PROVIDERS_API_PREFIX from @/constants to keep the two in sync. Minor DRY-ness win; the path is unlikely to change, but it would prevent drift.

Security considerations

The wildcard expansion (http://*, https://*, http://*:*, https://*:*) is still gated on an explicit, admin-only route, and the change does not broaden what data is exposed — it only relaxes origin validation during OIDC discovery for provider creation. Since POST /api/identity-providers is authenticated and authorization-guarded upstream (admin permission), this looks like an acceptable trade-off and is consistent with the existing /sso/register handling.

Verdict

LGTM. Ship it once CI is green. The nits above are optional cleanup.
· Branch