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.