دليل مصادقة MCP في Claude Code 2026

What is MCP?

MCP (Model Context Protocol) is an open standard developed by Anthropic that allows Claude Code to communicate with external systems in a structured way.
Instead of stuffing tool logic into the prompt, MCP creates a clear middleware layer. Claude calls the tool in a standard format. The MCP server receives the request and forwards it to the real system behind it, such as a database, internal API, cloud service, or ticket management system.

You can think of the MCP server as an adapter layer. One side is Claude Code. The other side is your physical infrastructure. It helps both sides understand each other without having to rewrite everything from scratch every time an integration occurs.

Without MCP, Claude Code only responded to text. With MCP, it begins to interact with the real system. And from that point on, it's no longer just "AI answering for fun."

Why MCP authentication matters

As MCP becomes more popular, I see many people using Claude Code to connect directly to internal systems. Some just call API tests. Others connect directly to services running on AWS with tight IAM.

The problem is: as soon as Claude can call the tool, it represents some kind of identity within your system.

If the authentication configuration is loose, the risk won't appear immediately. It's insidious. Like when I debugged a CloudFront configuration at. It was just a seemingly harmless forward header rule. No 500 errors, no downtime. But in reality, the access boundary was expanded more than expected. You have to carefully examine the logs to find the problem.

The same applies to MCP. If you choose the wrong authentication method, you could inadvertently:

• Expose your long-term API key
• Distribute access keys to multiple different users
• Grant Claude too many privileges than necessary.

Connecting to a manufacturing database or financial system on AWS will no longer a minor issue

Therefore, choosing the right authentication method isn't just about "getting the connection working." It can determine the security and consistency of the entire system behind it.

Why is authentication the first thing to consider?

These external tools are far from "harmless." They can contain source code, client records, production data, and internal tickets. But when Claude connects via MCP, it's not just reading for fun. It is acting as a verified identity deep inside your system. If the authentication is weak, you could be attacked. No complex attack is needed. One leaked API key is all it takes for things to go south very quickly.

The situation I encountered was similar. The service only provides a single token for both the development and production environments. Everything would be fine if that token information wasn't leaked during testing of a repository. Therefore, we need to change login credentials for both the production and development environments to avoid problems arising as soon as they are discovered. So, the system itself isn't the problem; the crucial issue lies in how you manage permissions. Authorization isn't just an add-on; it determines what Claude can do within its permitted scope, preventing security risks.

What is this article addressing?

Claude Code supports several different authentication methods. For example:

• API key
• Bearer token
• OAuth
• AWS credential (Access Key or assume role)

It's confusing at first glance. Each method exists for its own reason. There is no "right way for all cases."

Choosing the wrong method can lead to:

• Credential exposure
• Needing to re-configure midway
• Team wasting time fixing workflows

I once configured an MCP server running behind an API Gateway on AWS.

Initially, I used long-term access keys to speed up access. However, I realized this wasn't ideal compared to sharing keys with multiple testers for easy access. Ultimately, I switched to role-based assumptions to more clearly define permissions.

This article will delve into each point, explaining when to use each different method. The goal is to help you make the right choice from the start, avoiding future modifications.

Installing Claude Code

If you haven't installed Claude Code yet, you can set it up quickly.

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

MacOS Only

brew install --cask claude-code

Now move to the next sections about the authentication security

Defining Security in a CLI Environment

When running a CLI on a local machine, many people only think about HTTPS. Actually, the bigger issue lies in how you maintain your credentials.

HTTPS only protects data during transmission. It doesn't help if the token is exposed on your machine. In a CLI environment, the main issues are:

• Where do you store the key?
• How long does the token last?
• Who can use it?

Low security is when you leave a long-term API key in a plaintext config file. If that file is accidentally committed to the repository, it's over. That key is essentially out of control. And because it's a long-term key, you have to manually rotate it.

I once encountered a similar situation while debugging an environment issue with ECS. I was using the Amazon ECS MCP Server with an access key and secret key. After that, I forgot about those credentials. A few days later, I asked Claude to investigate some issues in another environment, but it was still using the old credentials, so it ended up performing many actions in the production environment.

High security is different. You use short-term tokens. Or referencing via environment variables. Or using service-level authentication mechanisms like IAM roles. For example, when using AWS SSO, tokens have a clear expiration date. After expiration, you have to log in again. If the machine is compromised, the attacker only has a very short window to do something. This method isn't perfect. But it minimizes damage if something goes wrong.

Below are four common authentication configuration methods for MCP servers in Claude Code. Each method is suitable for a different context.

1. Static HTTP Headers (API Keys & Bearer Tokens)

This is the easiest method to get started. This way will work well with many third-party services that use long-term API keys or Private Access Tokens (PATs).

Command Line Configuration

If you want to quickly add an MCP server with an authentication header, just use “claude mcp add” and pass “--header”

# Add a weather service MCP server with Bearer Token authentication
claude mcp add weather-service \
    --transport http \
    --header "Authorization: Bearer secret-token-123" \
    https://api.weather-data.com/mcp

When the process is complete, Claude will automatically write the configuration for you. No manual steps are needed. “Claude/settings.json”. This method is very convenient for quickly checking an external service.

I often use it when I need to test an API before officially integrating it into the system. Just remember one thing: Don't paste the actual token into the command and then commit the shell history somewhere. That happens more often than you think.

Configuration File (.claude/settings.json)

If don't want to put the token code in the file as plain text, you can use an environment variable.

Claude will read “${ENV_VAR}” and replace it with the actual value when the CLI starts.

For example:

{
  "mcpServers": {
    "data-tool": {
      "url": "https://api.myservice.com/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

This method is safer than writing the token directly to the file. You just need to export the environment variable before running Claude.

I once saw an internal repository accidentally commit a token to the config. Initially, I thought it was a private repository, so it was fine. Then the repository was shared with another team for testing. The production token was also included. Using environment variables doesn't solve all risks. But at least it reduces the chance of key exposure when committing by mistake.

Advantages:

• Easy to configure.
• Suitable for quick integration with external services.

Disadvantages:

• The token is still a long-term type.
• If exposed, you have to manually rotate it.

2.1 AWS MCP Credentials

2.1 Acess Key and Secret Key (for AWS-hosted MCP Servers)

If your MCP server is located at AWS, this is much more practical. You can use the existing AWS login credentials on your machine. Typically, this is configured via AWS configure or AWS SSO. Claude will inherit variables like:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_PROFILE

This is very available when the MCP server runs behind an API Gateway. Or when the backend is on Lambda or ECS and IAM authentication is enabled. 

Such as, configuring an MCP proxy to sign requests using Signature V4:

{
  "mcpServers": {
    "cloud-logger": {
      "command": "node",
      "args": ["/path/to/aws-mcp-proxy.js"],
      "env": {
        "AWS_PROFILE": "my-dev-profile",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://my-mcp-service.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

Or, more simply, export environment variables before running Claude:

# Set AWS credentials before running Claude Code

export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-southeast-1

# Start Claude Code — the MCP server will use these credentials claude

Claude doesn't need to know the key details. It only uses the AWS context you're logged into.

I remember debugging an internal MCP server running behind an API Gateway. Requests were consistently returning 403 errors. At the time, I thought it was a policy issue. But then I discovered that the AWS SSO certificate on my machine had expired. Simply running the “aws sso login” command again fixed everything. Since then, I've always noted that registered services need to check the session before working on them, rather than blaming IAM.

مزايا:

• الرموز المميزة تكون عادة قصيرة الأجل عبر خدمة STS.
• يمكن تدويرها تلقائيًا.
• أمان أعلى من مفاتيح API طويلة الأجل.

عيوب:

• تعتمد على حالة تسجيل الدخول إلى AWS.
• يتوقف كل شيء فورًا بمجرد انتهاء الجلسة.

2.2. تولي دور IAM (أقل امتياز وصول)

عندما تستخدم بيانات اعتماد AWS مباشرة، يعمل Claude تحت هويتك الشخصية. هذا مريح، ولكنه ليس دائمًا الطريقة الصحيحة. يتيح تولي دور (Assume a Role) لـ MCP استخدام هوية منفصلة. هذه الهوية تخدم فقط جهازًا أو خدمة معينة. هذا مفيد جدًا عندما تريد محاكاة بيئة الإنتاج.

على سبيل المثال، اختبار كيفية عمل خدمة مع وصول للقراءة فقط. أو عندما يقبل خادم MCP دور IAM ثابتًا فقط. لا يسمح للمستخدمين الفرديين باستدعائه مباشرة.

واجهت حالة كهذه. كانت واجهة برمجة تطبيقات داخلية تسمح فقط لأدوار الواجهة الخلفية بالوصول إليها. تم حظر المستخدمين الفرديين. للاختبار محليًا، كان عليك تولي هذا الدور المحدد.

سير العمل واضح تمامًا:

1. تطلب تولي دور IAM.
2. تتحقق خدمة AWS STS مما إذا كان لديك الإذن لاستخدام sts:AssumeRole. إذا كان صالحًا، تُرجع STS بيانات اعتماد مؤقتة.
3. الـ وكيل MCP سيستخدم بيانات الاعتماد المؤقتة تلك لاستدعاء الخدمة المستهدفة. ترى الخدمة الدور فقط، وليس المستخدم الفردي الخاص بك.

ما يعجبني في هذه الطريقة هو وضوح الأذونات الشديد. للأدوار سياساتها الخاصة. إذا أردت فرض أي قيود، يمكنك تعديلها في تلك السياسة. الجانب السلبي هو أن التكوين الأولي يستغرق بعض الوقت. إذا كانت سياسة الثقة خاطئة ولو بسطر واحد، فلن ينجح التولي. وتصحيح أخطاء IAM ليس مهمة ممتعة أبدًا.

مثال على التكوين

{
  "mcpServers": {
    "finance-bot": {
      "command": "node",
      "args": ["/path/to/aws-role-mcp-proxy.js"],
      "env": {
        "ASSUME_ROLE_ARN": "arn:aws:iam::123456789012:role/mcp-finance-bot-role",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://secure-finance.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

إعداد أذونات IAM لتولي الأدوار

لتولي دور، يجب أن يمتلك مستخدمك الحالي تلك الصلاحية. بدون سياسة الثقة الصحيحة، سيتوقف كل شيء فورًا.

عادةً، سأقوم بتعريف بعض المتغيرات لتبسيط الأمر:

# تعريف المتغيرات

export ACCOUNT_ID="123456789012"
export ROLE_NAME="mcp-finance-bot-role"
export MY_USER_ARN="arn:aws:iam::${ACCOUNT_ID}:user/developer@company.com"

# تحديث سياسة الثقة للدور للسماح لمستخدمك بتوليه

aws iam update-assume-role-policy \
    --role-name "${ROLE_NAME}" \
    --policy-document '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "'"${MY_USER_ARN}"'"},
        "Action": "sts:AssumeRole"
      }]
    }

يقوم هذا القسم بشكل أساسي بشيء واحد فقط. يخبر AWS أن مستخدمك مسموح له بتولي هذا الدور.

لقد أضعت ذات مرة فترة ما بعد الظهر بأكملها تقريبًا لمجرد أنني كنت أفتقد ARN الصحيح في سياسة الثقة. كانت السياسة المرفقة بالدور صحيحة. لكن سياسة الثقة لم تسمح للمستخدم بالتولي. ونتيجة لذلك، استمرت STS في إرجاع خطأ AccessDenied. نقطة أخرى يجب تذكرها:

يوجد تأخير بسيط في IAM. بعد تحديث السياسة، قد تضطر إلى الانتظار دقيقة أو دقيقتين حتى يصبح ساري المفعول. إذا فشل الاختبار فورًا، فلا داعي للذعر.

المزايا:

• يحافظ على مبدأ الحد الأدنى من الصلاحيات.
• كل ما يمكن للدور فعله يقع ضمن سياسته.

العيوب:

• التكوين معقد بعض الشيء.
• خطأ صغير واحد فقط ولن يعمل.

3. دعم OAuth 2.0 المدمج

بالنسبة لخدمات الطرف الثالث المعقدة مثل GitHub أو Linear أو Slack، لا يكفي مفتاح API. فهي تتطلب تسجيل الدخول عبر تدفق مستخدم قياسي. يوفر Claude Code دعم OAuth مدمجًا لهذه الأنواع من خوادم MCP.

أوامر Shell

لا تحتاج إلى كتابة تدفق تسجيل الدخول الخاص بك. قبل البدء، يمكنك التحقق من الخوادم التي تتطلب المصادقة:

# List the MCP servers that need authentication
claude mcp list

إذا رأيت أي خوادم غير مسجلة الدخول، فما عليك سوى تشغيل:

# Start the login flow for a GitLab MCP server (opens browser)
claude mcp auth gitlab-server

أوامر تفاعلية

هناك ميزة مريحة. إذا كنت تستخدم Claude وواجهت خطأ في الصلاحيات، فلا تحتاج إلى الخروج. يمكنك المصادقة مباشرة داخل جلسة الدردشة. 

مثال: 

>>> أنت: اذكر مهامي.

>>> كلود: أحتاج إلى الوصول إلى Linear.

>>> /mcp auth linear-server

ما عليك سوى كتابة هذا الأمر. سيعيد كلود تنشيط تدفق تسجيل الدخول. عادةً، سيفتح المتصفح لتأكيد الأذونات.

صادفت مرة موقفًا انتهت فيه صلاحية رمز Linear المميز بينما كنت أراجع مشكلة. أبلغ كلود عن عدم كفاية الأذونات في منتصف الطريق.

 بدلاً من إعادة تشغيل واجهة سطر الأوامر (CLI)، قمت فقط بتشغيل "/mcp auth" وتم الأمر. عدت إلى العمل فورًا بعد ذلك.

المزايا:

• تدفق OAuth قياسي.
• يتم تحديث الرموز المميزة تلقائيًا.
• تجربة سلسة إلى حد ما عند العمل مع مستخدم.

العيوب:

• في بعض الأحيان، لا يزال يتعين عليك فتح المتصفح وتسجيل الدخول مرة أخرى. خاصة عند تبديل أجهزة الكمبيوتر أو عند انتهاء جلسة تسجيل الدخول.

ملخص

يعتمد اختيار طريقة المصادقة على أمرين:

• مكان تخزين بيانات الاعتماد الخاصة بك.
• والمشكلة التي تحلها.

لا يوجد خيار "الأفضل لجميع الأماكن". بل الخيار الذي يناسب السياق فقط. ملاحظة صغيرة ولكنها مهمة: تأكد من أن بيئة Node.js لديك مستقرة أولاً. اكتشفت أخيرًا أن الجهاز المحلي كان يستخدم إصدار Node خاطئًا. بمجرد تغييره إلى "nvm useيجب أن يعمل بشكل طبيعي. يساعد استخدام nvm في تجنب العديد من الأخطاء غير المبررة الناتجة عن عدم تطابق البيئات. لا تستهين بهذا. 

دليل سريع: إضافة خوادم MCP في Claude Code

نقل HTTP مع رأس المصادقة

# نقل HTTP مع رأس المصادقة

claude mcp add my-server \
    --transport http \
    --header "Authorization: Bearer ${MY_TOKEN}" \
    https://my-mcp-server.com/mcp

# نقل Stdio (عملية محلية)

claude mcp add my-local-server \
    -- node /path/to/server.js

# عرض خوادم MCP المهيأة

claude mcp list

# إزالة خادم MCP

claude mcp remove my-server

يكفي تذكر هذه الأوامر للبدء. أما الباقي فيتعلق باختيار طريقة المصادقة المناسبة للموقف المناسب.

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

كيفية إنشاء رمز OAuth لـ Claude Code MCP؟

لإنشاء رمز OAuth لـ Claude Code MCP، عادةً ما تقوم بالدمج مع موفر OAuth يصدر رموز وصول قصيرة الأجل. تساعد هذه الطريقة عالية الأمان في منع التعرض المباشر لبيانات الاعتماد طويلة الأجل لاتصالات Claude Code MCP الخاصة بك. تعتمد الخطوات المحددة على إعداد موفر OAuth الذي اخترته وتكامله مع Claude Code.

هل يمكن لـ Claude Code الوصول إلى خوادم MCP؟

نعم، يمكن لـ Claude Code الوصول إلى خوادم MCP، مما يتيح التفاعل مع الأنظمة الخارجية مثل قواعد البيانات وواجهات برمجة التطبيقات (APIs). تحول هذه الوظيفة Claude Code من مجرد مستجيب نصي إلى مشارك نشط في النظام. تعد المصادقة الفعالة لـ Claude Code MCP أمرًا حيويًا للعمليات الآمنة، حيث تمنع الوصول غير المصرح به وتضمن سلامة البيانات عبر البنية التحتية الأمريكية.

كيفية مصادقة Figma MCP في Claude Code؟

لمصادقة Figma MCP في Claude Code، ستحتاج إلى اختيار طريقة مصادقة آمنة لـ Claude MCP. يتضمن ذلك عادةً استخدام مفاتيح API، أو OAuth، أو رموز Bearer، اعتمادًا على تكامل Figma وسياسات الأمان الخاصة بك. ركز على منح أقل الامتيازات وتجنب المفاتيح طويلة الأجل لضمان تفاعل آمن للنظام.