Authentification MCP dans le curseur : OAuth, clés d'API et configuration sécurisée (Guide 2026)

L'authentification MCP dicte la manière dont l'agent IA de Cursor prouve de qui il s'agit lorsqu'il fait appel à des outils et à des services externes. Ignorez-le, et chaque serveur MCP fonctionne en mode ouvert ou s'appuie sur un jeton statique en texte clair. Si vous faites les choses correctement, l'agent se connecte à GitHub, à Slack ou à vos API internes avec des informations d'identification délimitées, rotatives et vérifiables.

Le Spécification MCP a obtenu une autorisation OAuth 2.1 standardisée dans son mars 2025 révision. juin 2025 suivi en séparant officiellement les serveurs MCP des serveurs d'autorisation et en exigeant des métadonnées de ressources protégées (RFC 9728). Puis le Révision de novembre 2025 a introduit les documents de métadonnées d'identification du client (CIMD) comme méthode d'enregistrement par excellence et a rendu le PKCE non négociable pour tous les clients. Cursor a fourni le support OAuth en v1.0 en juin 2025, le plaçant parmi les premiers IDE à proposer une authentification MCP basée sur un navigateur.

Pour comprendre le modèle d'authentification de Cursor, vous devez consacrer deux temps à la compréhension du modèle d'authentification : il régit ce que votre agent peut toucher et il définit le rayon d'action en cas de panne.

Comment fonctionne l'authentification MCP

L'authentification MCP se situe au niveau de la couche transport. Le mécanisme que vous obtenez dépend du fait que le serveur s'exécute localement via stdio ou à distance via Streamable HTTP.

Serveurs de studio gérer entièrement l'authentification en dehors du protocole MCP. Le processus serveur hérite des variables d'environnement de Cursor, généralement des clés ou des jetons d'API, et les utilise pour s'authentifier auprès de services en amont tels que l'API GitHub, une base de données ou un fournisseur de cloud. La spécification MCP est explicite ici : les implémentations de stdio doivent extraire les informations d'identification de l'environnement, et non d'un flux OAuth.

Serveurs distants sur Streamable HTTP suivez un autre chemin. La spécification MCP recommande OAuth 2.1, et la poignée de main implique trois parties :

Le curseur joue le rôle de client OAuth. Le serveur MCP fonctionne comme un serveur de ressources OAuth 2.1 : il valide les jetons mais ne les émet jamais. Un serveur d'autorisation (Okta, Auth0, Azure AD ou un serveur géré par l'opérateur du serveur MCP) se charge de l'authentification des utilisateurs et distribue des jetons.

Voici la séquence réelle. Le curseur lance une requête sur le serveur MCP sans aucun jeton attaché. Le serveur revient avec 401 Unauthorized et un en-tête WWW-Authenticate qui pointe vers Métadonnées de ressources protégées document. Le curseur saisit ce document, détermine à quel serveur d'autorisation parler, s'enregistre lui-même (via Dynamic Client Registration ou CIMD) et vous renvoie dans une fenêtre de navigateur pour vous connecter.

Une fois que vous avez autorisé, le serveur d'autorisation émet un jeton d'accès. Le curseur cache ce jeton et l'attache à chaque demande suivante.

PCE (Proof Key for Code Exchange) parcourt l'ensemble du flux. Le curseur génère une paire code_verifier et code_challenge avant de démarrer. Même si un attaquant parvient à intercepter le code d'autorisation en plein vol, il ne peut pas l'échanger contre un jeton sans le vérificateur d'origine.

Méthodes d'authentification dans Cursor

Le curseur vous propose trois méthodes pour authentifier les serveurs MCP. Chacune correspond à un scénario de déploiement différent.

Variables d'environnement pour les serveurs stdio

La plupart des serveurs MCP locaux prouvent leur identité aux API en amont par le biais de variables d'environnement. Le curseur les injecte dans le processus du serveur au moment du lancement.

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

Le champ env accepte des paires clé-valeur. Le curseur les dirige directement vers le processus généré. Votre jeton n'apparaîtra pas dans l'interface utilisateur ou les journaux de Cursor. Mais il se trouve en texte brut dans mcp.json. Confiez ce fichier à Git, et vous venez d'envoyer vos informations d'identification à tous les collaborateurs, ou pire encore, à un dépôt public.

Atténuation : Référencez les variables d'environnement au niveau du système à l'aide de la syntaxe $ {env:VARIABLE_NAME} plutôt que de coller des valeurs brutes :

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

Désormais, le véritable jeton se trouve dans votre profil shell ou dans un gestionnaire de secrets. Le fichier mcp.json ne contient qu'un pointeur, vous pouvez donc en contrôler la version en toute sécurité.

En-têtes statiques pour serveurs distants

Certains serveurs distants ne prennent pas en charge OAuth. Pour ceux-ci, vous pouvez transmettre une clé d'API statique ou un jeton Bearer dans les en-têtes HTTP. Cursor envoie ces en-têtes avec chaque demande au point de terminaison du serveur.

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

La syntaxe de référence des variables d'environnement fonctionne également dans les en-têtes :

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

Les en-têtes statiques sont extrêmement simples à configurer. Ils présentent également tous les inconvénients des informations d'identification à longue durée de vie : aucune expiration, aucune portée par session, et leur rotation vous oblige à toucher le fichier de configuration de chaque développeur.

OAuth 2.1 pour serveurs distants

OAuth est ce que la spécification MCP recommande réellement pour les serveurs distants, et Cursor v1.0 a apporté un support natif. Voici à quoi ressemble l'expérience de bout en bout :

1. Déposez l'URL d'un serveur distant dans mcp.json. Aucun en-tête d'authentification n'est nécessaire.
2. Ouvrir Paramètres du curseur → Outils et MCP. Le serveur apparaît en bleu Connecter bouton et une étiquette « Nécessite une authentification » sous son nom.
3. Frappez Connecter. Le curseur ouvre votre navigateur par défaut sur la page de connexion du serveur d'autorisation.
4. Connectez-vous et accordez les autorisations demandées.
5. Une fois que vous avez autorisé, le navigateur redirige vers cursor : //anysphere.cursor-mcp/oauth/callback. Votre système d'exploitation renvoie le rappel vers Cursor, qui échange le code d'autorisation contre les jetons via PKCE avec S256.
6. Les outils du serveur apparaissent dans la liste des outils MCP, prêts à être appelés par l'agent.

La configuration JSON d'un serveur basé sur OAuth semble minimale car elle est minimal :

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

Pas de jetons. Pas d'en-têtes. Cursor gère tout à travers le flux de découverte de la spécification : les métadonnées des ressources protégées du serveur indiquent à Cursor où aller, et PKCE verrouille l'échange de jetons.

Les liens profonds en un clic fonctionnent également bien avec OAuth. Cliquez sur le lien « Ajouter au curseur » sur la page de documentation d'un serveur, et Cursor déclenche immédiatement le flux OAuth si le serveur en a besoin.

Risques liés à la sécurité de

L'authentification MCP ouvre une surface d'attaque à chaque étape du cycle de vie des informations d'identification : comment les stocker, les envoyer, les échanger et les révoquer. Plusieurs vulnérabilités malveillantes l'ont clairement démontré tout au long de 2025.

CVE-2025-6514 : Injection de commandes via OAuth Discovery

Recherche sur la sécurité chez JFrog a découvert une faille critique (CVSS 9.6) dans mcp-remote, un package npm populaire qui assurait le proxy des connexions OAuth pour les clients MCP, curseur inclus. Le problème ? Le package a saisi l'URL authorization_endpoint du serveur MCP auquel il s'est connecté et ne l'a jamais nettoyée.

Un opérateur de serveur non autorisé pourrait insérer des commandes shell dans l'URL de ce point de terminaison. Lorsque mcp-remote a essayé d'ouvrir l'URL dans un navigateur, le système d'exploitation a exécuté les commandes intégrées au lieu de charger une page Web.

Les versions 0.0.5 à 0.1.15 ont été affectées. Plus de 437 000 téléchargements. Cloudflare, Hugging Face et Auth0 avaient tous fait référence à mcp-remote dans leurs documents d'intégration MCP. Le correctif a atterri dans la version 0.1.16.

La vulnérabilité remonte essentiellement au modèle de confiance OAuth : le client MCP a demandé à un serveur non fiable « Où dois-je envoyer mon utilisateur pour qu'il se connecte ? » puis j'ai suivi aveuglément la réponse. Le correctif a ajouté la validation et la désinfection des URL avant que quoi que ce soit ne soit transmis aux gestionnaires du système.

Prise de contrôle de compte en un clic sur des serveurs MCP distants

Obsidian Security a supprimé un ensemble de vulnérabilités liées au piratage de compte en un clic sur des serveurs MCP de production gérés par des organisations renommées. Le point commun entre tous ces serveurs : la plupart des serveurs MCP font office de proxys OAuth : ils prennent un code d'autorisation de Cursor et l'échangent contre des jetons avec le service en amont.

Ce qui n'a pas fonctionné était structurel. Ces serveurs n'ont pas réussi à lier les paramètres d'état OAuth aux sessions utilisateur. Ils n'ont pas correctement appliqué le consentement. Un attaquant pourrait créer un lien qui acheminerait un code d'autorisation vers un URI de redirection contrôlé par l'attaquant.

Obsidian a déposé les rapports entre juillet et août 2025. Les fournisseurs les ont corrigés en septembre. La mise à jour des spécifications MCP de novembre 2025 a ajouté des directives de sécurité explicites couvrant ces modèles d'attaque exacts. À noter : seuls 3 des 78 serveurs d'autorisation MCP testés par Obsidian prenaient réellement en charge la CIMD à l'époque. L'adoption des nouvelles caractéristiques techniques a été lente.

Vulnérabilités du client MCP via les flux OAuth

Obsidian a également été signalé des bogues critiques dans les clients MCP eux-mêmes : Gemini-CLI, VS Code, Windsurf et Cherry Studio ont tous rencontré des problèmes (CVE-2025-54074 et trois CVE associés). La catégorie de faille était l'exécution de code à distance par le biais d'une gestion bâclée des URL d'autorisation.

Lorsqu'un client MCP ouvrait un authorization_endpoint contrefait via le gestionnaire d'URL du système, un attaquant pouvait exécuter des commandes de système d'exploitation arbitraires sur la machine du développeur. La spécification d'autorisation MCP ne restreint pas les modèles d'URL. Par conséquent, les schémas file ://, javascript : ou spécifiques à la plate-forme peuvent être utilisés si le client ignorait la validation.

Informations d'identification en texte brut dans mcp.json

Le risque le plus courant ne nécessite pas de numéro CVE. Toute clé d'API que vous déposez dans mcp.json se trouve en texte clair sur votre système de fichiers. Si ce fichier se retrouve dans le répertoire d'un projet et que quelqu'un le valide dans Git, les informations d'identification sont divulguées à tous les collaborateurs, et peut-être à toutes les personnes sur Internet s'il s'agit d'un dépôt public. Les variables d'environnement nécessitent au moins un accès au shell. Mais mcp.json est un fichier de configuration versionné que les développeurs partagent régulièrement, sans hésiter.

Comment la spécification MCP Auth a évolué

La spécification d'autorisation MCP a subi trois réécritures majeures en 2025. Chacune corrigeait de véritables failles découvertes dans la version précédente.

La révision de juin 2025 a été la plus importante. Avant ce changement, chaque développeur de serveurs MCP devait créer ses propres points de terminaison d'autorisation. Cela a effectivement obligé chaque auteur de serveur à devenir un implémenteur OAuth, une mauvaise idée si vous vous souciez de la sécurité. La spécification mise à jour a transféré l'émission de jetons à des fournisseurs d'identité dédiés (Okta, Auth0, Azure AD), comme cela fonctionne depuis des années en entreprise.

Novembre 2025 a abordé de front l'enregistrement des clients. Le DCR était un casse-tête car la plupart des serveurs d'autorisation d'entreprise ne l'activent pas immédiatement. Le CIMD évite ce problème : chaque client publie un document de métadonnées à une URL connue, et les serveurs d'autorisation prennent des décisions de confiance en se basant uniquement sur le domaine. Plus propre, plus pratique et plus convivial pour les environnements d'entreprise verrouillés.

Authentification d'entreprise avec une passerelle MCP

Un seul développeur peut suivre une poignée de clés d'API sans trop de problèmes. Une équipe ne le peut pas. Dix développeurs utilisant chacun cinq serveurs MCP créent cinquante configurations d'informations d'identification distinctes : aucune visibilité centralisée sur qui peut accéder à quoi, pas de rotation automatique des clés, pas de piste d'audit.

Une passerelle MCP regroupe tout cela en un seul endroit. Passerelle MCP de TrueFoundry prend en charge trois méthodes d'authentification lorsque vous enregistrez des serveurs MCP en amont :

• Aucune autorisation : Pour les environnements de démonstration ou les API publiques. Ne convient pas à la production.
• Authentification d'en-tête statique : Pour les serveurs qui utilisent des clés d'API ou des jetons statiques. La passerelle stocke les informations d'identification de manière centralisée et les injecte dans chaque demande sortante.
• OAuth2 et DCR : Pour les serveurs qui implémentent OAuth. La passerelle exécute l'intégralité du flux OAuth, stocke les jetons par utilisateur et les actualise automatiquement avant leur expiration.

Le modèle de fonctionnement ressemble à l'authentification unique, sauf pour MCP. Les développeurs s'authentifient une seule fois auprès de TrueFoundry, soit via un jeton d'accès personnel (PAT), soit via le fournisseur d'identité de leur organisation (Okta, Azure AD). La passerelle associe cette identité aux informations d'identification en aval appropriées pour chaque serveur MCP. Les développeurs individuels ne touchent jamais directement un jeton OAuth.

Du côté de l'administrateur, vous organisez les serveurs en Groupes de serveurs MCP et attribuez l'accès par équipe ou par rôle. Un développeur débutant peut bénéficier d'un accès en lecture seule à GitHub. Un ingénieur senior obtient un accès complet à GitHub et un accès en écriture à JIRA. La passerelle applique ces limites au niveau du protocole, et non via les fichiers de configuration du système d'honneur.

Voici une présentation détaillée de configuration de l'authentification Okta OAuth2 avec des serveurs MCP via la passerelle, couvrant le provisionnement des serveurs d'autorisation, la gestion de l'étendue et la configuration de l'actualisation des jetons.

Meilleures pratiques pour l'authentification MCP dans Cursor

• Ne confiez jamais de secrets à mcp.json. Utilisez la syntaxe de référence $ {env:Var} pour les serveurs stdio. Utilisez OAuth sur des serveurs distants. Si les en-têtes statiques sont votre seule option, référencez-y également les variables d'environnement.
• Préférez OAuth aux jetons statiques pour tout ce qui est distant. Les jetons OAuth expirent. Vous pouvez les délimiter. Vous pouvez les révoquer. Les jetons statiques ne font rien de tout cela.
• Épinglez votre version de mcp-remote si vous en dépendez. La CVE-2025-6514 a prouvé qu'un proxy OAuth non corrigé peut compromettre l'ensemble de votre environnement de développement. Exécutez npx -y mcp-remote @0 .1.16 ou version ultérieure, jamais @latest en production.
• Limitez la portée des jetons de manière agressive. Lorsque Cursor vous guide dans un flux OAuth, accordez le strict minimum. Lecture seule pour la recherche de code. Accès en écriture uniquement lorsque l'agent a réellement besoin de créer des problèmes ou de fusionner des PR.
• Auditez régulièrement vos serveurs connectés. Accédez à Paramètres du curseur → Outils et MCP et passez en revue ce qui est actif. Tuez tout ce que vous n'utilisez plus. Chaque serveur connecté est un identifiant actif en mémoire.
• Gardez le curseur à jour. Chaque version inclut des améliorations de gestion OAuth et des correctifs de sécurité. Une version obsolète de Cursor signifie qu'un code d'authentification obsolète s'exécute sur votre machine.

Conclusion

L'authentification MCP dans Cursor couvre un large éventail, allant d'une clé d'API en texte brut dans un fichier JSON à un flux OAuth 2.1 complet avec PKCE, en passant par l'enregistrement dynamique et l'actualisation automatique des jetons. Le choix de la bonne méthode dépend du modèle de déploiement du serveur et du sérieux que vous accordez à votre posture de sécurité.

Pour le développement local, les variables d'environnement associées à la syntaxe $ {env:Var} empêchent le contrôle de version des informations d'identification. Pour les services à distance, OAuth supprime complètement la gestion manuelle des jetons de l'équation. Et pour les équipes ou les entreprises, une passerelle MCP telle que TrueFoundry centralise le stockage des informations d'identification, applique l'accès basé sur les rôles et vous fournit une piste d'audit complète pour chaque connexion MCP.

Explorez Passerelle MCP de TrueFoundry ou réservez une démo pour voir l'authentification MCP centralisée en action.

Questions fréquemment posées

Quelles sont les méthodes d'authentification prises en charge par Cursor pour les serveurs MCP ?

Cursor en propose trois : des variables d'environnement injectées dans les processus du serveur stdio local, des en-têtes HTTP statiques (jetons Bearer ou clés d'API) pour les serveurs distants et OAuth 2.1 avec PKCE pour les serveurs distants exécutant la spécification d'autorisation MCP. La prise en charge d'OAuth est disponible depuis Cursor v1.0, qui a été expédiée en juin 2025.

Comment fonctionne OAuth pour MCP dans Cursor ?

Lorsque vous ajoutez un serveur MCP distant qui nécessite OAuth, Cursor suit les spécifications d'autorisation MCP. Il trouve le serveur d'autorisation via les métadonnées des ressources protégées (RFC 9728), s'enregistre en tant que client, ouvre votre navigateur pour que vous puissiez vous connecter et accorder des autorisations, puis échange le code d'autorisation contre les jetons à l'aide de PKCE. Le curseur maintient les jetons en toute sécurité et les actualise automatiquement lorsqu'ils sont sur le point d'expirer.

Est-il sûr de stocker des clés d'API dans mcp.json ?

Insérer des clés d'API brutes dans mcp.json signifie stocker les informations d'identification en texte brut sur le disque. Si ce fichier est validé dans le contrôle de version, la clé est divulguée. Utilisez plutôt la syntaxe de référence $ {env:VARIABLE_NAME} : elle extrait les valeurs de votre environnement système au moment de l'exécution. Pour les serveurs distants, préférez OAuth, qui supprime complètement les informations d'identification statiques.

Qu'est-ce que la vulnérabilité de mcp-remote ?

CVE-2025-6514 était un bogue critique d'injection de commandes (CVSS 9.6) dans le package mcp-remote npm, affectant les versions 0.0.5 à 0.1.15. JFrog Security Research a découvert que le package transmettait les URL des points de terminaison d'autorisation OAuth aux gestionnaires du système sans aucune désinfection. Un serveur MCP malveillant pourrait créer une URL qui exécuterait des commandes de système d'exploitation arbitraires sur la machine du développeur. La version 0.1.16 a livré le correctif.

Comment les entreprises gèrent-elles l'authentification MCP à grande échelle ?

Avec une passerelle MCP qui prend en charge toute la gestion des informations d'identification. La passerelle de TrueFoundry stocke et actualise les jetons OAuth par utilisateur, associe les identités organisationnelles aux informations d'identification MCP en aval et applique des politiques d'accès basées sur les rôles. Les développeurs se connectent une seule fois et ne traitent plus jamais des jetons de serveur MCP individuels.

Cursor prend-il en charge CIMD pour l'enregistrement des clients OAuth ?

Pas encore, début 2026. Le curseur s'appuie toujours sur l'enregistrement dynamique des clients (DCR) pour ses flux OAuth. La spécification MCP de novembre 2025 a introduit le CIMD comme méthode d'enregistrement préférée, mais des publications sur le forum communautaire datant de janvier 2026 suggèrent que la fonctionnalité n'a pas été livrée. Entre-temps, le DCR continue de fonctionner correctement pour la plupart des serveurs MCP compatibles OAuth.