# Neon turns Managed Better Auth into an OAuth provider for MCP servers — with a branch-isolation trap Neon's November 2 OAuth Provider plugin lets applications and MCP servers use the same managed OAuth 2.1 authorisation server. Its branch-aware tokens require exact issuer and audience checks, while the provider plugin and SDK are still labelled beta in the technical documentation. Neon now manages OAuth discovery, token issuance and refresh for apps and MCP clients, but developers still host login/consent pages and verify access in their own resource servers. Shared signing keys across branches make issuer pinning essential. - Status: Active - Published: 2026-11-03T06:36:15+13:00 - Updated: 2026-11-03T06:36:15+13:00 - Categories: Artificial Intelligence, Web Development, AI Agents, Developer Tools - Tags: Authentication, Better Auth, Model Context Protocol, Neon, OAuth 2.1 - Canonical HTML: https://beyondthe.news/dossiers/neon-managed-better-auth-oauth-provider-mcp-issuer-branch ## What changed On November 2, 2026, Neon announced OAuth Provider support for Managed Better Auth, enabling an OAuth 2.1 authorisation server for external applications, APIs and MCP servers. A single managed plugin handles OAuth and MCP discovery, authorisation code with PKCE, token issuance/refresh and client onboarding via Client ID Metadata Documents (CIMD) by default, with legacy dynamic client registration optional. Neon provides discovery endpoints, JWKS and managed token issuance; developers still supply login and consent pages and run their protected API or MCP server. The @neon/oauth SDK provides Express, Hono, Next.js and node:http helpers. Although the blog says available now, Neon's detailed documentation labels the OAuth Provider plugin and SDK beta. ## Why it matters MCP server builders can avoid writing and operating a bespoke OAuth issuer, and apps can offer 'Sign in with your app' using the same auth identity as their Neon Postgres data. The significant security boundary is per-branch isolation: Neon branches share signing keys, so a token with a valid signature may belong to a different branch. Resource servers must check the exact iss and aud claims, not merely the signature. Untrusted MCP clients can self-identify using metadata documents, so consent UX and resource scoping remain developer responsibilities. ## One managed OAuth server, multiple resource types Managed Better Auth now serves OAuth 2.1 metadata, OpenID discovery, JWKS, authorisation code with PKCE and refresh flows. Developers register an MCP server URL or other protected resource, create login/consent pages, and mount token verification in their API or MCP transport. The @neon/oauth SDK's createMcpAuth checks signature, issuer and audience and exposes Express, Hono, Next.js and Node HTTP adapters. An MCP client can discover the issuer from protected-resource metadata and request a resource-specific token. ## Client onboarding has two different trust models Client ID Metadata Documents (CIMD) are enabled by default for MCP resources and allow compatible clients to self-onboard with HTTPS metadata. Legacy dynamic client registration is disabled by default but can be enabled for older clients. Self-registered clients cannot skip consent, and a client-controlled display name is not proof of identity. Managed clients are required for ordinary API resources; trusted first-party clients can be configured separately. Developers should show the redirect destination, scopes and resource in consent UI. ## Branches share keys, not identity context Each Neon branch has its own OAuth issuer and copies auth configuration when branched. All branches of a project share signing keys, however. A token issued on a preview branch may verify cryptographically against production's JWKS, but should be rejected because its iss differs. The aud must also identify the exact protected API or MCP server. Neon warns that signature-only checks break branch isolation; @neon/oauth verifies both claims. ## Beta boundaries and developer obligations Neon runs the OAuth issuer but not the developer's login page, consent page, API, MCP tool implementation or business-level authorisation. The documentation marks OAuth Provider and @neon/oauth as beta despite the availability announcement. The SDK's cookie-based sign-in uses node:crypto and does not run in an Edge runtime, though token verification can. Existing issued tokens remain valid until expiry when a resource is removed. Refresh tokens rotate and require careful concurrency handling. ## Key details - Announced November 2, 2026; OAuth Provider plugin and @neon/oauth SDK labelled beta in current documentation. - OAuth 2.1 authorisation code + PKCE, JWKS, OIDC/OAuth discovery, access and refresh tokens. - MCP protected-resource metadata and CIMD self-onboarding by default; legacy dynamic client registration opt-in. - Developers must host their own login and consent pages, and their own API/MCP resource servers. - Neon branch issuers differ but signing keys are shared; verify both iss and aud, not just signature. - Access tokens are EdDSA JWTs when the resource parameter is supplied, with one-hour lifetime. - Managed Better Auth included on Neon Free plan up to 60,000 monthly active users; exact plan limits can change. - @neon/oauth SDK beta has adapters for Express, Hono, Next.js and node:http. ## Builder takeaways - Use a branch-specific issuer URL and exact audience validation in every MCP/API resource server. - Build and test login/consent pages before enabling third-party MCP clients; show redirect URI, scopes and resource. - Prefer CIMD for modern MCP clients and leave legacy DCR disabled unless a client requires it. - Do not mistake a verified JWT signature for proof that it came from the production branch. - Keep business authorisation (which orders, records or tools a user can access) separate from token authentication. - Test on a preview branch, but remember branches clone user and client data and must remain isolated by issuer. ## What to watch - GA status of the OAuth Provider plugin and @neon/oauth SDK, and any security audit. - MCP client interoperability with CIMD versus DCR and consent flows. - Issuer, token refresh and audience validation regressions across Neon branches. - Further official examples and migration guides for protected MCP servers. ## Uncertainties - The provider and SDK are documented as beta; independent production reliability and security testing were not established. - No independently measured adoption or performance results are available. - The release announcement describes availability now, but beta labels mean production support commitments should be verified. ## Sources - [Managed Better Auth OAuth provider for MCP](https://neon.com/blog/managed-better-auth-oauth-provider-mcp) — Neon · primary · 2026-11-02T00:00:00+13:00. Later beta-labelled OAuth Provider plugin, distinct from September GA. - [OAuth Provider guide](https://neon.com/docs/auth/guides/plugins/oauth-provider) — Neon · primary documentation · 2026-11-03T00:00:00+13:00. Beta label, token issuer/audience requirements, CIMD/DCR, consent, SDK version and limitations. - [The Neon backend is GA: a complete set of primitives so agents can build](https://neon.com/blog/neon-backend-is-ga) — Neon · primary · 2026-09-17T00:00:00+12:00. GA status, branch-aware Functions/Object Storage/Auth/AI Gateway and free allowances.