مصادقة MCP في Cursor: 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، امنح الحد الأدنى فقط من الصلاحيات. قراءة فقط للبحث في الكود. وصول للكتابة فقط عندما يحتاج الوكيل حقًا إلى إنشاء مشكلات أو دمج طلبات السحب (PRs).
• راجع خوادمك المتصلة بصفة دورية. انتقل إلى إعدادات Cursor ← الأدوات و MCP واستعرض ما هو نشط. أوقف أي شيء لم تعد تستخدمه. كل خادم متصل يمثل بيانات اعتماد نشطة موجودة في الذاكرة.
• حافظ على تحديث Cursor. يتضمن كل إصدار تحسينات في معالجة OAuth وتصحيحات أمنية. إصدار Cursor قديم يعني رمز مصادقة قديم يعمل على جهازك.

الخلاصة

تغطي مصادقة MCP في Cursor نطاقًا واسعًا — بدءًا من مفتاح API بنص عادي في ملف JSON وصولاً إلى تدفق OAuth 2.1 الكامل مع PKCE، والتسجيل الديناميكي، والتحديث التلقائي للرمز المميز. يعتمد اختيار الطريقة الصحيحة على نموذج نشر الخادم ومدى جديتك في موقفك الأمني.

للتطوير المحلي، تبقي متغيرات البيئة المقترنة بصيغة ${env:VAR} بيانات الاعتماد خارج نظام التحكم في الإصدار. بالنسبة للخدمات عن بعد، يزيل OAuth إدارة الرمز المميز اليدوية من المعادلة تمامًا. وبالنسبة للفرق أو الشركات، فإن بوابة MCP مثل TrueFoundry تُركز تخزين بيانات الاعتماد، وتفرض الوصول المستند إلى الأدوار، وتوفر لك سجل تدقيق كامل عبر كل اتصال MCP.

استكشف بوابة MCP من TrueFoundry أو احجز عرضًا توضيحيًا لترى مصادقة MCP المركزية قيد العمل.

الأسئلة الشائعة

ما هي طرق المصادقة التي يدعمها Cursor لخوادم MCP؟

يوفر Cursor ثلاثة خيارات: متغيرات البيئة المحقونة في عمليات خادم الإدخال/الإخراج القياسي المحلي، ورؤوس HTTP الثابتة (رموز Bearer أو مفاتيح API) للخوادم البعيدة، وOAuth 2.1 مع PKCE للخوادم البعيدة التي تشغل مواصفات ترخيص MCP. يتوفر دعم OAuth منذ Cursor v1.0، الذي تم إصداره في يونيو 2025.

كيف يعمل OAuth لـ MCP في Cursor؟

عند إضافة خادم MCP بعيد يتطلب OAuth، يتبع Cursor مواصفات ترخيص MCP. يعثر على خادم الترخيص عبر بيانات تعريف الموارد المحمية (RFC 9728)، ويسجل نفسه كعميل، ويفتح متصفحك لتتمكن من تسجيل الدخول ومنح الأذونات، ثم يستبدل رمز التفويض بالرموز المميزة باستخدام PKCE. يحتفظ Cursor بالرموز المميزة بشكل آمن ويقوم بتحديثها تلقائيًا عندما توشك على الانتهاء.

هل تخزين مفاتيح API في mcp.json آمن؟

وضع مفاتيح API الخام في ملف mcp.json يعني تخزين بيانات الاعتماد كنص عادي على القرص. إذا تم إيداع هذا الملف في نظام التحكم بالإصدارات، فسيتسرب المفتاح. استخدم بدلاً من ذلك صيغة الإشارة ${env:VARIABLE_NAME} — فهي تسحب القيم من بيئة نظامك في وقت التشغيل. بالنسبة للخوادم البعيدة، يفضل استخدام OAuth، الذي يلغي الحاجة إلى بيانات الاعتماد الثابتة تمامًا.

ما هي ثغرة mcp-remote الأمنية؟

كانت CVE-2025-6514 ثغرة خطيرة لحقن الأوامر (CVSS 9.6) في حزمة npm mcp-remote، والتي أثرت على الإصدارات من 0.0.5 إلى 0.1.15. اكتشفت أبحاث JFrog الأمنية أن الحزمة قامت بإعادة توجيه عناوين URL لنقاط نهاية ترخيص OAuth إلى معالجات النظام دون أي تنقية. يمكن لخادم MCP خبيث إنشاء عنوان URL يقوم بتنفيذ أوامر نظام تشغيل عشوائية على جهاز المطور. تم إصدار الإصلاح في الإصدار 0.1.16.

كيف تدير الشركات مصادقة MCP على نطاق واسع؟

باستخدام بوابة MCP تتولى إدارة جميع بيانات الاعتماد. تقوم بوابة TrueFoundry بتخزين وتحديث رموز OAuth المميزة على أساس كل مستخدم، وتربط الهويات التنظيمية ببيانات اعتماد MCP النهائية، وتفرض سياسات الوصول المستندة إلى الأدوار. يسجل المطورون الدخول مرة واحدة ولا يتعاملون مع رموز خادم MCP الفردية مرة أخرى.

هل يدعم Cursor CIMD لتسجيل عميل OAuth؟

ليس بعد، اعتبارًا من أوائل عام 2026. لا يزال Cursor يعتمد على تسجيل العميل الديناميكي (DCR) لتدفقات OAuth الخاصة به. قدمت مواصفات MCP لشهر نوفمبر 2025 CIMD كطريقة التسجيل المفضلة، لكن منشورات المنتدى المجتمعي من يناير 2026 تشير إلى أن الميزة لم يتم إصدارها بعد. يستمر DCR في العمل بشكل جيد لمعظم خوادم MCP التي تدعم OAuth في هذه الأثناء.