Per User OAuth in a Next.js MCP Server (Step by Step) A developer has implemented per-user OAuth authentication in a Next.js MCP server, solving the problem of shared API keys that expose one user's data to another. The solution creates a new MCP server instance inside each Route Handler request, allowing tool closures to capture the authenticated user's personal OAuth token from the session before execution. This approach uses NextAuth with custom JWT and session callbacks to store the scoped access token in an encrypted session cookie, ensuring each user's API calls use their own credentials rather than a shared token. Your MCP server is using one shared API key for every caller. That works in a demo. The second you need each user to call a tool with their credentials their GitHub token, their Notion workspace, their Stripe key a shared key blows up. Here's how to wire per user OAuth into a Next.js MCP server so each session gets its own scoped token. When you build an MCP server the usual way, tools look like this: js server.tool "get-my-repos", {}, async = { const octokit = new Octokit { auth: process.env.GITHUB TOKEN } ; const { data } = await octokit.repos.listForAuthenticatedUser ; return { repos: data.map r = r.full name }; } ; That GITHUB TOKEN is yours . Every user who connects to this server gets results from your account. In a multitenant setup, that's a footgun. Alice calls get-my-repos and sees Bob's repos. Bob calls create-issue and writes to Alice's project. You need each MCP session to carry its own OAuth token. Here's how to do it without reinventing the session layer. Three pieces fit together: The key insight: your Route Handler runs in a request context, so it has full access to the session. You create the MCP server instance inside that handler, which means every tool closure captures the authenticated user's token before it runs. Install what you need: npm install next-auth @auth/core @octokit/rest Configure NextAuth to store the OAuth access token in the session. Critically, you need the jwt and session callbacks. By default NextAuth does not expose the raw access token to your session object: python // src/app/api/auth/ ...nextauth /route.ts import NextAuth from "next-auth"; import GitHub from "next-auth/providers/github"; export const { handlers, auth } = NextAuth { providers: GitHub { clientId: process.env.GITHUB CLIENT ID , clientSecret: process.env.GITHUB CLIENT SECRET , authorization: { params: { scope: "repo read:user" }, }, } , , callbacks: { async jwt { token, account } { // account is only present on the initial sign-in if account { token.accessToken = account.access token; } return token; }, async session { session, token } { session.accessToken = token.accessToken as string; return session; }, }, } ; export const { GET, POST } = handlers; And extend the session type so TypeScript doesn't complain: js // src/types/next-auth.d.ts import { DefaultSession } from "next-auth"; declare module "next-auth" { interface Session extends DefaultSession { accessToken: string; } } After a user signs in with GitHub, session.accessToken is their personal GitHub token scoped to repo read:user . It's stored in their encrypted session cookie, not anywhere on your server. This is the important part. Your MCP transport lives inside a Route Handler at /api/mcp : js // src/app/api/mcp/route.ts import { createMcpHandler } from "@vercel/mcp-adapter"; import { auth } from "@/app/api/auth/ ...nextauth /route"; export const POST = async request: Request = { // Read the session for THIS request const session = await auth ; if session?.accessToken { return new Response "Unauthorized", { status: 401 } ; } // Create a new MCP handler instance for this request. // The tool registrations close over session — each call gets its own. const handler = createMcpHandler server = { server.tool "get-my-repos", { description: "Lists repositories the current user has access to", inputSchema: { type: "object", properties: { visibility: { type: "string", enum: "all", "public", "private" , default: "all", }, }, }, }, async { visibility = "all" } = { const response = await fetch https://api.github.com/user/repos?visibility=${visibility}&per page=20 , { headers: { Authorization: Bearer ${session.accessToken} , Accept: "application/vnd.github+json", }, } ; if response.ok { throw new Error GitHub API returned ${response.status} ; } const repos = await response.json ; return { content: { type: "text", text: repos .map r: { full name: string; private: boolean } = ${r.full name} ${r.private ? "private" : "public"} .join "\n" , }, , }; } ; }, {}, { redisUrl: process.env.REDIS URL } ; return handler request ; }; The session.accessToken in the tool handler is captured from the outer POST function scope. It's the token for whoever made this request. Two users hitting /api/mcp at the same moment get two separate MCP handler instances, each with their own token. No global state. No shared credentials. Each request is isolated. Once the pattern is in place, adding tools is just adding more server.tool calls inside the same closure. They all get session for free: server.tool "create-issue", { description: "Creates a GitHub issue in a repo the current user owns", inputSchema: { type: "object", required: "repo", "title" , properties: { repo: { type: "string", description: "owner/repo format" }, title: { type: "string" }, body: { type: "string" }, }, }, }, async { repo, title, body } = { const owner, repoName = repo.split "/" ; const response = await fetch https://api.github.com/repos/${owner}/${repoName}/issues , { method: "POST", headers: { Authorization: Bearer ${session.accessToken} , Accept: "application/vnd.github+json", "Content-Type": "application/json", }, body: JSON.stringify { title, body } , } ; if response.ok { const err = await response.json ; throw new Error err.message || GitHub API returned ${response.status} ; } const issue = await response.json ; return { content: { type: "text", text: Created: ${issue.html url} } , }; } ; This tool creates an issue on the calling user's behalf . If you'd wired this with a shared token, every issue would be created by your service account. With per user tokens, it's the actual user: their name on the issue, their rate limits, their permissions. Here's a quick check before you ship. Sign in as two different GitHub accounts and grab each session cookie from the browser DevTools. Then run both calls at the same time: Alice's session curl -s -X POST http://localhost:3000/api/mcp \ -H "Cookie: next-auth.session-token=