Support built-in authentication in the Cloudflare host #1793

Problem

host-cloudflare currently requires Cloudflare Access. The Worker returns an unavailable response when ACCESS_TEAM_DOMAIN or ACCESS_AUD is absent.

This requirement makes Cloudflare Access part of the host's security and deployment model. Operators who can run Workers and D1 but cannot or do not want to enroll in Zero Trust cannot use the hosted Worker deployment.

host-selfhost already provides built-in Better Auth sessions, API keys, owner bootstrap, invitations, and MCP OAuth. The Cloudflare host already consumes neutral IdentityProvider, AccountProvider, and McpAuthProvider seams.

Proposal

Add an opt-in built-in authentication mode to host-cloudflare. Keep Cloudflare Access as the existing default.

AUTH_MODE=access
AUTH_MODE=builtin

The built-in mode would:

• store Better Auth records in the existing D1 database;
• mount Better Auth under /api/auth/*;
• authenticate browser sessions, bearer sessions, and personal API keys;
• provide MCP OAuth discovery, dynamic client registration, PKCE, and consent;
• make the first account the owner, then require single-use invitations;
• map each authenticated user to the existing stable Principal shape;
• preserve the current per-user integration credential and MCP session isolation.

Proposed structure

Extract the reusable Better Auth policy from host-selfhost. Keep storage and lifecycle code in host-specific adapters.

• Shared code owns the Better Auth plugin configuration, identity mapping, account provider, MCP OAuth provider, and consent handling.
• host-selfhost keeps its libSQL adapter and process lifecycle.
• host-cloudflare adds a Drizzle D1 adapter, checked-in migrations, Worker configuration, and route composition.
• The existing Cloudflare Access provider remains unchanged and selectable.

This structure avoids copying the self-host auth stack into the Cloudflare application. It also keeps the execution runtime independent of the authentication mode.

Security requirements

The implementation must:

• claim the first owner account atomically;
• validate and consume invitation codes atomically;
• validate trusted origins and OAuth redirect URIs;
• require PKCE and explicit MCP consent;
• bind each MCP session to the authenticated organization and account;
• fail closed when the built-in auth secret is absent;
• keep ENABLE_DEV_AUTH unavailable as a production fallback;
• apply auth migrations idempotently.

The current self-host bootstrap and invitation flows should be reviewed for concurrent signup races during the extraction.

Delivery sequence

1. Extract the shared Better Auth policy without changing self-host behavior.
2. Add the D1 adapter and built-in Worker identity and account providers.
3. Add Worker MCP OAuth, setup, login, and invitation flows.
4. Add end-to-end coverage for Access mode and built-in mode.

Completion criteria

The feature is complete when a Worker with no Cloudflare Access variables can:

• bootstrap one owner account;
• reject an uninvited later signup;
• authenticate the browser and an MCP client through OAuth;
• isolate two users' stored integration credentials and MCP sessions;
• restart without losing auth state;
• run the existing Cloudflare Access mode without behavior changes.

Architecture question

Would you prefer this as an AUTH_MODE option in host-cloudflare, or as a separate Cloudflare host entry point that reuses the same runtime package?

I am willing to implement this as staged pull requests after we agree on the package boundary.