Guide d'authentification MCP dans Claude Code 2026

Qu'est-ce que le MCP ?

Le MCP (Model Context Protocol) est un standard ouvert développé par Anthropic qui permet à Claude Code de communiquer avec des systèmes externes de manière structurée.
Au lieu d'insérer la logique de l'outil dans l'invite, MCP crée une couche intergicielle claire. Claude appelle l'outil dans un format standard. Le serveur MCP reçoit la demande et la transmet au système réel qui la sous-tend, tel qu'une base de données, une API interne, un service cloud ou un système de gestion des tickets.

Vous pouvez considérer le serveur MCP comme une couche d'adaptateur. L'un des côtés est celui de Claude Code. De l'autre côté, il y a votre infrastructure physique. Cela permet aux deux parties de se comprendre sans avoir à tout réécrire à partir de zéro à chaque intégration.

Sans MCP, Claude Code n'a répondu qu'au texte. Avec MCP, il commence à interagir avec le système réel. À partir de ce moment, il ne s'agit plus simplement de « l'IA qui répond pour le plaisir ».

Pourquoi l'authentification MCP est importante

Au fur et à mesure que MCP gagne en popularité, je vois de nombreuses personnes utiliser Claude Code pour se connecter directement à des systèmes internes. Certains appellent simplement des tests d'API. D'autres se connectent directement aux services exécutés sur AWS avec une IAM stricte.

Le problème est le suivant : dès que Claude peut appeler l'outil, il représente une sorte d'identité au sein de votre système.

Si la configuration d'authentification n'est pas correcte, le risque n'apparaîtra pas immédiatement. C'est insidieux. Comme lorsque j'ai débogué une configuration CloudFront sur. C'était juste une règle d'en-tête avant apparemment inoffensive. Pas de 500 erreurs, pas de temps d'arrêt. Mais en réalité, la limite d'accès a été élargie plus que prévu. Vous devez examiner attentivement les journaux pour trouver le problème.

Il en va de même pour le MCP. Si vous choisissez la mauvaise méthode d'authentification, vous pourriez par inadvertance :

• Exposez votre clé API à long terme
• Distribuez les clés d'accès à plusieurs utilisateurs différents
• Accordez à Claude trop de privilèges que nécessaire.

La connexion à une base de données de fabrication ou à un système financier sur AWS ne sera plus un problème mineur

Par conséquent, choisir la bonne méthode d'authentification ne se limite pas à « faire fonctionner la connexion ». Il peut déterminer la sécurité et la cohérence de l'ensemble du système qui le sous-tend.

Pourquoi l'authentification est-elle la première chose à prendre en compte ?

Ces outils externes sont loin d'être « inoffensifs ». Ils peuvent contenir du code source, des dossiers clients, des données de production et des tickets internes. Mais lorsque Claude se connecte via MCP, ce n'est pas juste pour le plaisir de lire. Il agit comme une identité vérifiée au plus profond de votre système. Si l'authentification est faible, vous pourriez être attaqué. Aucune attaque complexe n'est nécessaire. Une seule clé API divulguée suffit pour que les choses tournent mal très rapidement.

La situation que j'ai rencontrée était similaire. Le service ne fournit qu'un seul jeton pour les environnements de développement et de production. Tout irait bien si ces informations de jeton n'étaient pas divulguées lors du test d'un référentiel. Par conséquent, nous devons modifier les informations de connexion pour les environnements de production et de développement afin d'éviter que des problèmes ne surviennent dès leur découverte. Le problème n'est donc pas le système lui-même, mais la question cruciale réside dans la façon dont vous gérez les autorisations. L'autorisation n'est pas simplement un module complémentaire ; elle détermine ce que Claude peut faire dans le cadre autorisé, afin de prévenir les risques de sécurité.

Quel est le sujet de cet article ?

Claude Code prend en charge plusieurs méthodes d'authentification différentes. Par exemple :

• Clé API
• Jeton au porteur
• OAuth
• Identifiant AWS (clé d'accès ou rôle d'acteur)

À première vue, c'est confus. Chaque méthode existe pour sa propre raison. Il n'existe pas de « solution adaptée à tous les cas ».

Le choix de la mauvaise méthode peut entraîner :

• Exposition liée aux titres
• Nécessité de reconfigurer à mi-chemin
• L'équipe perd du temps à régler les flux de travail

Une fois, j'ai configuré un serveur MCP s'exécutant derrière une passerelle API sur AWS.

Au départ, j'utilisais des clés d'accès à long terme pour accélérer l'accès. Cependant, je me suis rendu compte que ce n'était pas l'idéal par rapport au partage de clés avec plusieurs testeurs pour un accès facile. En fin de compte, je suis passé à des hypothèses basées sur les rôles afin de définir plus clairement les autorisations.

Cet article approfondira chaque point et expliquera quand utiliser chaque méthode différente. L'objectif est de vous aider à faire le bon choix dès le départ, en évitant de futures modifications.

Installation de Claude Code

Si vous n'avez pas encore installé Claude Code, vous pouvez le configurer rapidement.

macOS, Linux, WSL :

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

Windows PowerShell :

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

macOS uniquement

brew install --cask claude-code

Passez maintenant aux sections suivantes concernant la sécurité de l'authentification

Définition de la sécurité dans un environnement CLI

Lors de l'exécution d'une CLI sur une machine locale, de nombreuses personnes ne pensent qu'au HTTPS. En fait, le plus gros problème réside dans la façon dont vous conservez vos informations d'identification.

Le protocole HTTPS protège uniquement les données lors de leur transmission. Cela n'aide pas si le jeton est exposé sur votre machine. Dans un environnement CLI, les principaux problèmes sont les suivants :

• Où entreposez-vous la clé ?
• Combien de temps dure le jeton ?
• Qui peut l'utiliser ?

Faible niveau de sécurité c'est lorsque vous laissez une clé d'API à long terme dans un fichier de configuration en texte brut. Si ce fichier est accidentellement enregistré dans le dépôt, c'est terminé. Cette clé est essentiellement incontrôlable. Et comme il s'agit d'une clé à long terme, vous devez la faire pivoter manuellement.

Une fois, j'ai rencontré une situation similaire lors du débogage d'un problème d'environnement avec ECS. J'utilisais le serveur Amazon ECS MCP avec une clé d'accès et une clé secrète. Après cela, j'ai oublié ces informations d'identification. Quelques jours plus tard, j'ai demandé à Claude d'étudier certains problèmes dans un autre environnement, mais celui-ci utilisait toujours les anciennes informations d'identification. Il a donc fini par effectuer de nombreuses actions dans l'environnement de production.

Haute sécurité est différent. Vous utilisez des jetons à court terme. Ou le référencement via des variables d'environnement. Ou en utilisant des mécanismes d'authentification au niveau du service tels que les rôles IAM. Par exemple, lorsque vous utilisez AWS SSO, les jetons ont une date d'expiration claire. Après expiration, vous devez vous reconnecter. Si la machine est compromise, l'attaquant ne dispose que d'un très court laps de temps pour agir. Cette méthode n'est pas parfaite. Mais cela minimise les dégâts en cas de problème.

Vous trouverez ci-dessous quatre méthodes de configuration d'authentification courantes pour les serveurs MCP dans Claude Code. Chaque méthode est adaptée à un contexte différent.

1. En-têtes HTTP statiques (clés d'API et jetons porteurs)

Il s'agit de la méthode la plus simple pour démarrer. Cette méthode fonctionnera bien avec de nombreux services tiers qui utilisent des clés API à long terme ou des jetons d'accès privés (PAT).

Configuration de la ligne de commande

Si vous souhaitez ajouter rapidement un serveur MCP avec un en-tête d'authentification, utilisez simplement »claude mcp ajouter» et passez « --en-tête»

# 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

Une fois le processus terminé, Claude rédigera automatiquement la configuration pour vous. Aucune étape manuelle n'est nécessaire. »Claude/settings.json». Cette méthode est très pratique pour vérifier rapidement un service externe.

Je l'utilise souvent lorsque je dois tester une API avant de l'intégrer officiellement au système. N'oubliez pas une chose : ne collez pas le jeton réel dans la commande, puis validez l'historique du shell quelque part. Cela arrive plus souvent que vous ne le pensez.

Fichier de configuration (.claude/settings.json)

Si vous ne souhaitez pas placer le code du jeton dans le fichier sous forme de texte brut, vous pouvez utiliser une variable d'environnement.

Claude va lire »$ {ENV_VAR}» et remplacez-la par la valeur réelle au démarrage de la CLI.

Par exemple :

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

Cette méthode est plus sûre que l'écriture du jeton directement dans le fichier. Il vous suffit d'exporter la variable d'environnement avant d'exécuter Claude.

Une fois, j'ai vu un dépôt interne valider accidentellement un jeton dans la configuration. Au départ, je pensais que c'était un dépôt privé, donc c'était bien. Le référentiel a ensuite été partagé avec une autre équipe à des fins de test. Le jeton de production était également inclus. L'utilisation de variables d'environnement ne résout pas tous les risques. Mais au moins, cela réduit le risque d'exposition majeure en cas de commission par erreur.

Avantages :

• Facile à configurer.
• Convient pour une intégration rapide avec des services externes.

Inconvénients :

• Le jeton est toujours un type à long terme.
• S'il est exposé, vous devez le faire pivoter manuellement.

2.1 Informations d'identification AWS MCP

2.1 Clé d'accès et clé secrète (pour les serveurs MCP hébergés sur AWS)

Si votre serveur MCP se trouve sur AWS, c'est beaucoup plus pratique. Vous pouvez utiliser les informations de connexion AWS existantes sur votre machine. Généralement, cela est configuré via AWS configure ou AWS SSO. Claude héritera de variables telles que :

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• JETON DE SESSION AWS
• AWS_PROFILE

Cela est très disponible lorsque le serveur MCP s'exécute derrière une passerelle API. Ou lorsque le backend est sur Lambda ou ECS et que l'authentification IAM est activée.

Par exemple, la configuration d'un proxy MCP pour signer les demandes à l'aide de 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"
      }
    }
  }
}

Ou, plus simplement, exportez les variables d'environnement avant d'exécuter Claude :

# Définissez les informations d'identification AWS avant d'exécuter Claude Code

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

# Démarrez Claude Code — le serveur MCP utilisera ces informations d'identification claude

Claude n'a pas besoin de connaître les détails essentiels. Il utilise uniquement le contexte AWS auquel vous êtes connecté.

Je me souviens d'avoir débogué un serveur MCP interne exécuté derrière une passerelle API. Les requêtes renvoyaient régulièrement des erreurs 403. À l'époque, je pensais que c'était une question de politique. Mais j'ai découvert que le certificat AWS SSO de ma machine avait expiré. Il suffit d'exécuter le »connexion AWS SSOLa commande » a de nouveau tout corrigé. Depuis, j'ai toujours remarqué que les services enregistrés devaient vérifier la session avant de travailler dessus, plutôt que de blâmer IAM.

Avantages :

• Les jetons sont généralement à court terme via STS.
• Peut être pivoté automatiquement.
• Sécurité supérieure à celle des clés API à long terme.

Inconvénients :

• Dépend de l'état de connexion AWS.
• Tout s'arrête immédiatement une fois la session terminée.

2.2. Assumation du rôle IAM (accès avec le moindre privilège)

Lorsque vous utilisez directement des informations d'identification AWS, Claude agit sous votre identité personnelle. C'est pratique, mais ce n'est pas toujours la bonne méthode. Supposer qu'un rôle permet au MCP d'utiliser une identité distincte. Cette identité ne concerne qu'une machine ou un service spécifique. C'est très utile lorsque vous souhaitez simuler une production.

Par exemple, tester le fonctionnement d'un service avec un accès en lecture seule. Ou lorsque le serveur MCP n'accepte qu'un rôle IAM fixe. Il ne permet pas aux utilisateurs individuels de l'appeler directement.

J'ai rencontré un cas comme celui-ci. Une API interne autorisait uniquement les rôles du backend à y accéder. Des utilisateurs individuels ont été bloqués. Pour tester localement, vous deviez assumer ce rôle spécifique.

Le flux de travail est assez clair :

1. Vous demandez à assumer un rôle IAM.
2. AWS STS vérifie si vous êtes autorisé à utiliser STS:AssumeRole. S'il est valide, STS renvoie un identifiant temporaire.
3. Le Proxy MCP utilisera cette identification temporaire pour appeler le service cible. Le service ne voit que le rôle, pas votre utilisateur individuel.

Ce que j'aime dans cette méthode, ce sont les autorisations très claires. Les rôles ont leurs propres politiques. Si vous souhaitez imposer des restrictions, vous pouvez les ajuster dans cette politique. L'inconvénient est que la configuration initiale prend un peu de temps. Si la politique de confiance est erronée ne serait-ce que d'une ligne, l'hypothèse ne fonctionnera pas. Et déboguer IAM n'est jamais une tâche amusante.

Exemple de configuration

{
  "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"
      }
    }
  }
}

Configuration des autorisations IAM pour assumer des rôles

Pour assumer un rôle, votre utilisateur actuel doit disposer de cette autorisation. Sans une politique de confiance appropriée, tout s'arrêtera immédiatement.

En général, je vais définir quelques variables pour simplifier :

# Définissez des variables

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

# Mettez à jour la politique de confiance du rôle pour permettre à votre utilisateur de l'assumer

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"
      }]
    }

Cette section ne fait essentiellement qu'une chose. Il indique à AWS que votre utilisateur est autorisé à assumer ce rôle.

Une fois, j'ai perdu presque un après-midi entier simplement parce qu'il me manquait le bon ARN dans la politique de confiance. La politique associée au rôle était correcte. Mais la politique de confiance ne permettait pas à l'utilisateur d'assumer. Par conséquent, STS n'arrêtait pas de renvoyer une erreur AccessDenied. Autre point à retenir :

IAM a un léger retard. Après avoir mis à jour la politique, il se peut que vous deviez attendre une minute ou deux pour qu'elle entre en vigueur. Si le test échoue toujours immédiatement, ne paniquez pas.

Avantages :

• Maintient le principe des autorisations minimales.
• Tout ce qu'un rôle peut faire s'inscrit dans le cadre de sa politique.

Inconvénients :

• La configuration est un peu compliquée.
• Juste une petite erreur et ça ne marchera pas.

3. Support OAuth 2.0 intégré

Pour les services tiers complexes tels que GitHub, Linear ou Slack, une clé API ne suffit pas. Ils nécessitent une connexion via un flux utilisateur standard. Claude Code fournit un support OAuth intégré pour ces types de serveurs MCP.

Commandes Shell

Vous n'avez pas besoin de créer votre propre flux de connexion. Avant de commencer, vous pouvez vérifier quels serveurs nécessitent une authentification :

# List the MCP servers that need authentication
claude mcp list

Si vous voyez des serveurs qui ne sont pas connectés, exécutez simplement :

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

Commandes interactives

Il existe une fonctionnalité pratique. Si vous utilisez Claude et que vous rencontrez une erreur d'autorisation, vous n'avez pas besoin de quitter. Vous pouvez autoriser directement dans la session de chat.

Exemple :

>>> Vous : Dressez la liste de mes tâches.

>>> Claude : J'ai besoin d'accéder à Linear.

>>> Serveur linéaire /mcp auth

Tapez simplement cette commande. Claude va réactiver le flux de connexion. Habituellement, le navigateur s'ouvre pour vous permettre de confirmer les autorisations.

Une fois, j'ai rencontré une situation où le jeton linéaire a expiré alors que j'examinais un problème. Claude a signalé des autorisations insuffisantes à mi-chemin.

Au lieu de redémarrer la CLI, j'ai simplement exécuté »/mcp auth» et c'était fait. Je suis retourné au travail immédiatement après.

Avantages :

• Flux OAuth standard.
• Les jetons sont automatiquement actualisés.
• Une expérience assez fluide lorsque vous travaillez avec un utilisateur.

Inconvénients :

• De temps en temps, vous devez toujours ouvrir le navigateur et vous reconnecter. En particulier lorsque vous changez d'ordinateur ou lorsque la session de connexion se termine.

Résumé

Le choix de la méthode d'authentification dépend de deux choses :

• Où vous stockez vos informations d'identification.
• Et quel problème tu es en train de résoudre.

Il n'existe pas d'option « la meilleure pour tous les lieux ». Seulement celui qui correspond au contexte. Remarque mineure mais importante : assurez-vous d'abord que votre environnement Node.js est stable. J'ai finalement découvert que la machine locale utilisait la mauvaise version de Node. Il suffit de le remplacer par »utilisation de la NVM« devrait fonctionner normalement. L'utilisation de nvm permet d'éviter de nombreuses erreurs inexplicables dues à des incohérences d'environnement. Ne sous-estimez pas cela.

Guide rapide : ajout de serveurs MCP dans Claude Code

Transport HTTP avec en-tête Auth

# Transport HTTP avec en-tête d'authentification

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

# Transport en studio (processus local)

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

# Répertorier les serveurs MCP configurés

claude mcp list

# Supprimer un serveur MCP

claude mcp remove my-server

Il suffit de se souvenir de ces commandes pour commencer. Le reste consiste à choisir la méthode d'authentification adaptée à la situation.

Questions fréquemment posées

Comment générer le jeton Claude Code MCP OAuth ?

Pour générer un jeton Claude Code MCP OAuth, vous devez généralement intégrer un fournisseur OAuth qui émet des jetons d'accès à court terme. Cette méthode hautement sécurisée permet d'éviter l'exposition directe des informations d'identification à long terme pour vos connexions Claude Code MCP. Les étapes spécifiques dépendent de la configuration du fournisseur OAuth que vous avez choisi et de son intégration avec Claude Code.

Est-ce que Claude Code peut accéder aux serveurs MCP ?

Oui, Claude Code peut accéder aux serveurs MCP, ce qui permet d'interagir avec des systèmes externes tels que des bases de données et des API. Cette fonctionnalité transforme Claude Code d'un répondeur de texte en un participant actif au système. Une authentification MCP par code Claude efficace est vitale pour sécuriser les opérations, empêcher les accès non autorisés et garantir l'intégrité des données sur l'ensemble de l'infrastructure américaine.

Comment authentifier figma MCP dans Claude Code ?

Pour authentifier Figma MCP dans Claude Code, vous devez choisir une méthode d'authentification sécurisée Claude MCP. Cela implique généralement l'utilisation de clés d'API, de jetons OAuth ou de jetons Bearer, en fonction de l'intégration de Figma et de vos politiques de sécurité. Concentrez-vous sur l'octroi de privilèges minimaux et évitez les clés à long terme pour garantir une interaction sécurisée avec le système.