CursorにおけるMCP認証：OAuth、APIキー、および安全な設定（2026年版ガイド）

MCP authentication dictates how Cursor's AI agent proves who it is when reaching out to external tools and services. Skip it, and every MCP server either runs wide open or relies on a static token sitting in plaintext. Get it right, and the agent connects to GitHub, Slack, or your internal APIs with credentials that are scoped, rotatable, and auditable.

The MCP specification landed standardized OAuth 2.1 authorization in its March 2025 revision. June 2025 followed up by formally splitting MCP servers from authorization servers and requiring Protected Resource Metadata (RFC 9728). Then the November 2025 revision brought in Client ID Metadata Documents (CIMD) as the go-to registration method and made PKCE non-negotiable for every client. Cursor shipped OAuth support in v1.0 back in June 2025, putting it among the first IDEs to offer browser-based MCP authentication.

Two things make understanding Cursor's auth model worth your time: it governs what your agent can touch, and it defines the blast radius when something breaks.

How MCP Authentication Works

MCP authentication lives at the transport layer. What mechanism you get depends on whether the server runs locally over stdio or remotely over Streamable HTTP.

Stdio servers handle authentication outside the MCP protocol entirely. The server process inherits environment variables from Cursor — usually API keys or tokens — and uses those to authenticate against upstream services like the GitHub API, a database, or a cloud provider. The MCP specification is explicit here: stdio implementations should pull credentials from the environment, not from an OAuth flow.

Remote servers on Streamable HTTP follow a different path. The MCP specification recommends OAuth 2.1, and the handshake involves three parties:

Cursor plays the role of OAuth client. The MCP server functions as an OAuth 2.1 resource server — it validates tokens but never issues them. An authorization server (Okta, Auth0, Azure AD, or one the MCP server operator runs) takes care of user authentication and hands out tokens.

Here's the actual sequence. Cursor fires a request at the MCP server with no token attached. The server comes back with 401 Unauthorized and a WWW-Authenticate header that points to its Protected Resource Metadata document. Cursor grabs that document, figures out which authorization server to talk to, registers itself (through Dynamic Client Registration or CIMD), and drops you into a browser window for login.

Once you authorize, the authorization server issues an access token. Cursor stashes that token and attaches it to every subsequent request.

PKCE (Proof Key for Code Exchange) runs through the entire flow. Cursor generates a code_verifier and code_challenge pair before kicking things off. Even if an attacker manages to intercept the authorization code mid-flight, they can't swap it for a token without the original verifier.

Authentication Methods in Cursor

Cursor gives you three ways to authenticate MCP servers. Each one maps to a different deployment scenario.

Environment Variables for stdio Servers

Most local MCP servers prove their identity to upstream APIs through environment variables. Cursor injects these into the server process at launch time.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

The env field takes key-value pairs. Cursor hands them straight to the spawned process. Your token won't show up in Cursor's UI or logs. But it does sit in plaintext inside mcp.json. Commit that file to Git, and you've just shipped your credentials to every collaborator — or worse, a public repo.

Mitigation: Reference system-level environment variables using the ${env:VARIABLE_NAME} syntax rather than pasting raw values:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

Now the real token lives in your shell profile or a secrets manager. The mcp.json file holds only a pointer, so you can safely version-control it.

Static Headers for Remote Servers

Some remote servers don't support OAuth. For those, you can pass a static API key or Bearer token in HTTP headers. Cursor ships these headers along with every request to the server endpoint.

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

The environment variable reference syntax works in headers too:

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer ${env:INTERNAL_API_KEY}"
      }
    }
  }
}

Static headers are dead simple to set up. They also carry every downside of long-lived credentials: no expiration, no per-session scoping, and rotating them forces you to touch every developer's config file.

OAuth 2.1 for Remote Servers

OAuth is what the MCP specification actually recommends for remote servers, and Cursor v1.0 brought native support. Here's what the experience looks like end to end:

1. Drop a remote server URL into mcp.json — no auth headers needed.
2. Open Cursor Settings → Tools & MCP. The server shows up with a blue Connect button and a "Needs authentication" label under its name.
3. Hit Connect. Cursor pops open your default browser to the authorization server's login page.
4. Log in and grant the permissions it asks for.
5. After you authorize, the browser redirects to cursor://anysphere.cursor-mcp/oauth/callback. Your OS routes the callback back to Cursor, which swaps the authorization code for tokens via PKCE with S256.
6. The server's tools show up in the MCP tools list, ready for the agent to call.

The JSON config for an OAuth-backed server looks minimal because it is minimal:

{
  "mcpServers": {
    "linear": {
      "url": "https://mcp.linear.app/mcp"
    }
  }
}

No tokens. No headers. Cursor handles everything through the spec's discovery flow — the server's Protected Resource Metadata tells Cursor where to go, and PKCE locks down the token exchange.

One-click deep links also play nicely with OAuth. Click an "Add to Cursor" link on a server's docs page, and Cursor triggers the OAuth flow right away if the server needs it.

Authentication Security Risks

MCP authentication opens up attack surface at every point in the credential lifecycle: how you store them, send them, exchange them, and revoke them. Several nasty vulnerabilities made that clear throughout 2025.

CVE-2025-6514: Command Injection via OAuth Discovery

JFrog Security Research found a critical flaw (CVSS 9.6) in mcp-remote, a popular npm package that proxied OAuth connections for MCP clients — Cursor included. The issue? The package grabbed the authorization_endpoint URL from whatever MCP server it connected to and never sanitized it.

A rogue server operator could stuff shell commands into that endpoint URL. When mcp-remote tried opening the URL in a browser, the operating system executed the embedded commands instead of loading a web page.

Versions 0.0.5 through 0.1.15 were affected. Over 437,000 downloads. Cloudflare, Hugging Face, and Auth0 had all pointed to mcp-remote in their MCP integration docs. The fix landed in version 0.1.16.

At its core, the vulnerability traced back to the OAuth trust model: the MCP client asked an untrusted server "where should I send my user to log in?" and then blindly followed the answer. The patch added URL validation and sanitization before anything got passed to system handlers.

One-Click Account Takeover in Remote MCP Servers

Obsidian Security dropped a set of one-click account-takeover vulnerabilities in production MCP servers run by well-known organizations. The common thread across all of them: most MCP servers double as OAuth proxies — they take an authorization code from Cursor and trade it for tokens with the upstream service.

What went wrong was structural. These servers failed to bind OAuth state parameters to user sessions. They didn't enforce consent properly. An attacker could craft a link that funneled an authorization code to a redirect URI the attacker controlled.

Obsidian filed the reports between July and August 2025. Vendors patched them by September. The November 2025 MCP specification update added explicit security guidance covering these exact attack patterns. Worth noting: only 3 out of 78 MCP authorization servers Obsidian tested actually supported CIMD at the time. Adoption of newer spec features has been slow.

MCP Client Vulnerabilities via OAuth Flows

Obsidian also flagged critical bugs in MCP clients themselves — Gemini-CLI, VS Code, Windsurf, and Cherry Studio all had issues (CVE-2025-54074 and three related CVEs). The flaw category was Remote Code Execution through sloppy handling of authorization URLs.

When an MCP client opened a crafted authorization_endpoint via the system's URL handler, an attacker could run arbitrary OS commands on the developer's machine. The MCP authorization spec doesn't restrict URL schemes, so file://, javascript:, or platform-specific schemes could sail through if the client skipped validation.

Plaintext Credentials in mcp.json

The most common risk needs no CVE number. Any API key you drop into mcp.json sits in cleartext on your filesystem. If that file ends up in a project directory and somebody commits it to Git, the credential leaks to every collaborator — and possibly every person on the internet if it's a public repo. Environment variables at least require shell access. But mcp.json is a versioned config file that developers share routinely, without thinking twice.

How the MCP Auth Spec Evolved

The MCP authorization specification went through three major rewrites in 2025. Each one addressed real flaws uncovered in the previous version.

The June 2025 revision was the big one. Before that change, every MCP server developer had to build their own authorization endpoints. That effectively forced every server author into becoming an OAuth implementer — a terrible idea if you care about security. The updated spec offloaded token issuance to dedicated identity providers (Okta, Auth0, Azure AD), which is how enterprise auth has worked for years.

November 2025 tackled client registration head-on. DCR had been a headache because most enterprise authorization servers don't enable it out of the box. CIMD sidesteps that problem: each client publishes a metadata document at a well-known URL, and authorization servers make trust decisions based on the domain alone. Cleaner, more practical, and friendlier to locked-down enterprise environments.

Enterprise Authentication with an MCP Gateway

A single developer can keep track of a handful of API keys without much trouble. A team cannot. Ten developers each using five MCP servers creates fifty separate credential setups — no central visibility into who can access what, no automated key rotation, no audit trail.

An MCP Gateway puts all of that in one place. TrueFoundry's MCP Gateway supports three authentication methods when you register upstream MCP servers:

• No Auth: For demo environments or public APIs. Not suitable for production.
• Static Header Auth: For servers that use API keys or static tokens. The gateway stores the credential centrally and injects it into every outbound request.
• OAuth2 and DCR: For servers that implement OAuth. The gateway runs the full OAuth flow, stores per-user tokens, and refreshes them automatically before they expire.

The operating model resembles single sign-on but for MCP. Developers authenticate once with TrueFoundry — either through a Personal Access Token (PAT) or their org's identity provider (Okta, Azure AD). The gateway maps that identity to the right downstream credential for each MCP server. Individual developers never touch an OAuth token directly.

On the admin side, you organize servers into MCP Server Groups and assign access by team or role. A junior developer might get read-only GitHub access. A senior engineer gets full GitHub plus write access to JIRA. The gateway enforces those boundaries at the protocol level — not through honor-system config files.

Here is a detailed walkthrough for setting up Okta OAuth2 authentication with MCP servers through the gateway, covering authorization server provisioning, scope management, and token refresh configuration.

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

MCP Gateway Evaluation Checklist

A practical guide used by platform & infra teams

Best Practices for MCP Authentication in Cursor

• Never commit secrets to mcp.json. Use the ${env:VAR} reference syntax for stdio servers. Reach for OAuth on remote servers. If static headers are your only option, reference environment variables in those too.
• Prefer OAuth over static tokens for anything remote. OAuth tokens expire. You can scope them. You can revoke them. Static tokens do none of that.
• Pin your mcp-remote version if you depend on it. CVE-2025-6514 proved that one unpatched OAuth proxy can compromise your whole dev environment. Run npx -y mcp-remote@0.1.16 or later — never @latest in production.
• トークンのスコープを厳しく制限してください。 CursorがOAuthフローを案内する際は、必要最低限の権限のみを付与してください。コード検索には読み取り専用、エージェントが本当にイシューを作成したりPRをマージしたりする必要がある場合にのみ書き込みアクセスを許可してください。
• 接続されているサーバーを定期的に監査してください。 にアクセスして Cursor Settings → Tools & MCP アクティブなものを確認してください。不要になったものはすべて削除してください。接続されているすべてのサーバーは、メモリ内にアクティブな認証情報として存在しています。
• Cursorを最新の状態に保ってください。 各リリースには、OAuth処理の改善とセキュリティパッチが含まれています。古いCursorバージョンは、お使いのマシンで古い認証コードが実行されていることを意味します。

まとめ

CursorにおけるMCP認証は、JSONファイル内の平文APIキーから、PKCE、動的登録、自動トークン更新を備えた完全なOAuth 2.1フローまで、多岐にわたります。適切な方法を選択するかどうかは、サーバーのデプロイモデルと、セキュリティ体制をどれだけ真剣に考えているかによって決まります。

ローカル開発では、環境変数と${env:VAR}構文を組み合わせることで、認証情報をバージョン管理から除外できます。リモートサービスの場合、OAuthは手動でのトークン管理を完全に不要にします。そして、チームや企業向けには、次のようなMCPゲートウェイが TrueFoundryの 認証情報の保存を一元化し、ロールベースのアクセスを強制し、すべてのMCP接続にわたる完全な監査証跡を提供します。

を探索するか、 TrueFoundryのMCPゲートウェイ または デモを予約して 一元化されたMCP認証が実際に動作する様子をご覧ください。

よくある質問

CursorはMCPサーバー向けにどのような認証方法をサポートしていますか？

Cursorでは、ローカルのstdioサーバープロセスに注入される環境変数、リモートサーバー用の静的HTTPヘッダー（BearerトークンまたはAPIキー）、そしてMCP認証仕様を実行するリモートサーバー用のPKCE付きOAuth 2.1の3つの方法を提供しています。OAuthサポートは、2025年6月に出荷されたCursor v1.0から利用可能です。

CursorでMCPのOAuthはどのように機能しますか？

OAuthを必要とするリモートMCPサーバーを追加すると、CursorはMCP認証仕様に従います。保護リソースメタデータ（RFC 9728）を通じて認証サーバーを見つけ、クライアントとして自身を登録し、ログインして権限を付与できるようにブラウザを開き、その後PKCEを使用して認証コードをトークンと交換します。Cursorはトークンを安全に保持し、有効期限が近づくと自動的に更新します。

mcp.jsonにAPIキーを保存するのは安全ですか？

mcp.jsonに生のAPIキーを置くことは、資格情報をディスクに平文で保存することを意味します。そのファイルがバージョン管理にコミットされると、キーが漏洩します。代わりに${env:VARIABLE_NAME}参照構文を使用してください。これは実行時にシステム環境から値を読み込みます。リモートサーバーの場合、静的な資格情報を完全に排除するOAuthを推奨します。

mcp-remoteの脆弱性とは何でしたか？

CVE-2025-6514は、mcp-remote npmパッケージのバージョン0.0.5から0.1.15に影響を与える重大なコマンドインジェクションのバグ（CVSS 9.6）でした。JFrog Security Researchは、このパッケージがOAuth認証エンドポイントのURLをサニタイズせずにシステムハンドラーに転送していることを発見しました。悪意のあるMCPサーバーは、開発者のマシン上で任意のOSコマンドを実行するURLを構築することができました。バージョン0.1.16で修正が提供されました。

企業はMCP認証を大規模にどのように管理していますか？

すべての資格情報管理を引き受けるMCPゲートウェイを使用します。TrueFoundryのゲートウェイは、ユーザーごとにOAuthトークンを保存および更新し、組織のIDを下流のMCP資格情報にマッピングし、ロールベースのアクセスポリシーを適用します。開発者は一度ログインすれば、個々のMCPサーバーのトークンを再度扱う必要はありません。

CursorはOAuthクライアント登録にCIMDをサポートしていますか？

2026年初頭現在、まだサポートしていません。CursorはOAuthフローに引き続き動的クライアント登録（DCR）を利用しています。2025年11月のMCP仕様では、CIMDが推奨される登録方法として導入されましたが、2026年1月のコミュニティフォーラムの投稿によると、この機能はまだリリースされていないようです。その間、DCRはほとんどのOAuth対応MCPサーバーで引き続き問題なく機能しています。