Managed Better Auth now supports the OAuth Provider plugin, one of our most requested features. It turns your auth instance into an OAuth 2.1 authorization server, so other apps and MCP clients can sign users in with your app.
In Better Auth, OAuth provider and MCP are two separate plugins. In Managed Better Auth they're one. You enable the OAuth provider, add your MCP server URL in the same panel, and a single auth instance handles both:
- Sign in with your app. A companion web app, SPA, desktop app or CLI sends the user to your Auth URL, the user approves access, and the app gets an access token for your API.
- MCP servers. An MCP client connects to your server, finds your authorization server from the server's metadata, signs the user in, and gets a token that only works for that MCP server.
Managed Better Auth already lets your users sign in to your app with Google, GitHub, or Vercel. This adds the other direction.
Turn it on #
In the Console, go to Settings › Better Auth › OAuth provider. Add your login and consent page URLs, your MCP server URL, and any other APIs you want to protect. Or simply ask your agent:
What Neon runs, and what you run #
Like JWT and Organization, OAuth Provider is a managed plugin.
- Neon runs: the authorization server, the discovery endpoints (
/.well-known/oauth-authorization-server,/.well-known/openid-configuration), the JWKS, token issuance and refresh, and client onboarding (managed clients,Client ID Metadata Documents , and optional dynamic registration). - You run: a login page and a consent page in your own app, so you control what users see when they approve a client. You also run the API or MCP server that accepts the tokens, and the new@neon/oauth SDK handles the token side of that.
What you can build with it #
The same auth instance covers two use cases: protecting an MCP server, and letting your other apps sign users in with your app.
Protect an MCP server
Your MCP server has two jobs: publish its protected resource metadata, and verify access tokens. @neon/oauth does both:
createMcpAuth() checks each token's signature, issuer and audience. Adapters are also available for Hono, Next.js and node:http.
Clients onboard themselves. MCP clients that support Client ID Metadata Documents work with no setup, because CIMD is on by default once you set an MCP server. For older clients that only support dynamic client registration, switch on Allow MCP clients to dynamically register themselves.
You can build the whole thing on the Neon backend:
- Neon Functions hosts the server and gives it a public URL.
- Managed Better Auth is the authorization server.
- Your Lakebase Postgres database holds the data the tools return, plus the users allowed to see it.
More coming
We'll publish a full guide to building an MCP server on Neon soon.
Sign users in to your other apps
For your own companion apps, internal tools or partner integrations, create an OAuth client in the Console. It can be confidential (with a secret) or public (PKCE only), and because you trust it, it can skip the consent screen. createOAuth() handles discovery, PKCE sign-in with encrypted session cookies, refresh, and bearer-token checks for your API:
The token your API receives was issued by your auth instance, so the user's identity, roles and data all come from the same database.
New to Managed Better Auth? #
Managed Better Auth is Better Auth, run by Neon, inside the same backend as your database, Functions, Object Storage and AI Gateway. You can enable it in one click, with CLI neon neon-auth enable, or by asking your agent. Users, sessions and organizations live in your database in the neon_auth schema, so a permission check is a JOIN, and auth state branches with your data.
Included in the Free plan
Managed Better Auth is included on every Neon plan, with the Free plan covering you up to 60,000 monthly active users.
Try it on a branch first
OAuth is the kind of thing you want to get right before real users hit it: redirect URIs, consent screens, scopes, token checks. You don't have to test any of that in production. OAuth provider configuration is per branch, and because auth lives in your database, a new branch comes with a copy of your users, sessions, and auth configuration. Each branch also gets its own Auth URL, which is its own issuer.
So the loop looks like this:
- Create a preview branch from production.
- Point a test MCP server or client at the branch's Auth URL.
- Run real sign-in flows against copies of real accounts, and change login pages, consent pages, or clients as much as you like.
- When it works, apply the same configuration to production.
The branches stay isolated. All branches in a project share signing keys, so a preview branch's tokens have a valid signature everywhere, but the issuer is different. Verifiers like @neon/oauth pin the issuer, so a preview branch's tokens are rejected by your production servers.
Get started #
The OAuth Provider plugin is available now. Read the OAuth Provider guide, install the SDK with npm install @neon/oauth, or hand the whole setup to your agent:
Your agent works best if it already knows Neon. If you haven't set that up yet, run this in your project folder:
It installs the Neon agent skills and the Neon MCP server. If you set it up a while ago, run it again to get the latest skills.