Votre serveur MCP a une clé dans un .env ? Vous êtes dans la majorité, et la fenêtre se ferme

Ouvrez votre .env. Comptez les lignes qui commencent par MCP_*_TOKEN=. Si elles sont là depuis plus de trois mois, sans rotation, vous faites partie des 53 % de serveurs MCP encore en clés statiques.

Et la fenêtre pour migrer tranquillement vient de se fermer. Le 15 mars 2026, la spec MCP Authorization est passée en mandatory : OAuth 2.1, PKCE, Resource Indicators (RFC 8707). Ce n’est plus une recommandation. C’est ce que tous les nouveaux clients MCP, Claude Desktop, Cursor, n8n, ChatGPT, vont exiger pour se connecter à votre serveur dans les six prochains mois.

Astrix Security a analysé 5 200 implémentations open source : 53 % en clés statiques, 8,5 % en OAuth complet, le reste en mécanismes hybrides ou cassés. Pendant ce temps, Smithery.ai a exposé 3 000 serveurs et des milliers de clés volables. La CVE-2026-21852 sur Claude Code a montré qu’un simple override de ANTHROPIC_BASE_URL pouvait rediriger toutes vos clés vers le proxy d’un attaquant. Et l’incident Supabase MCP a prouvé qu’une clé statique partagée entre un agent IA et une base de production, c’est un compte à rebours.

Si vous avez déployé un ou plusieurs serveurs MCP en interne, maison, fork, ou hébergé, il est temps de migrer. Voici comment, en 4 étapes, sur 4 à 6 semaines.

Pourquoi votre .env est devenu un problème en 2026

Quand MCP a décollé fin 2024, l’authentification se résumait à passer un token statique dans un header. C’était simple, ça marchait, on déployait en cinq minutes. Si vous découvrez le protocole, notre introduction au Model Context Protocol pose les bases en deux minutes.

Trois choses ont changé depuis.

1. L’écosystème a explosé

On compte aujourd’hui plus de 10 000 serveurs MCP publics. Chacun avec ses clés. Chacun connecté à un agent IA qui peut potentiellement les exposer. La surface d’attaque a été multipliée par 50 en dix-huit mois.

2. Les agents IA leakent

Un agent qui répond à un prompt utilisateur peut, par construction, inclure dans sa sortie le contenu d’un tool call. Si ce contenu inclut un token, il finit dans une transcription, un log, parfois directement dans une réponse à l’utilisateur. Le rapport de Rafter sur l’audit logging MCP est sans appel : tool responses contain credentials, API keys, tokens, or PII without structured redaction.

3. La spec a tranché

Le 25 novembre 2025, la spec MCP Authorization a formalisé OAuth 2.1. Le 15 mars 2026, elle est passée en mandatory. RFC 8707 (Resource Indicators) impose que chaque token soit scopé à un serveur MCP précis, fini les tokens “passe-partout” qu’un serveur compromis peut rejouer ailleurs.

Pour le détail des vecteurs d’attaque récents, notre article MCP et sécurité : 30 CVE en 60 jours recense les patterns observés début 2026.

La spec MCP Authorization : ce qu’OAuth 2.1 + PKCE + RFC 8707 imposent vraiment

Dépouillons la spec. Trois exigences techniques, et leur traduction concrète pour un dev PME.

OAuth 2.1 + PKCE

Votre serveur MCP devient un OAuth 2.1 resource server. Il ne valide plus une clé statique, il valide un access token signé par votre Identity Provider (IdP). PKCE (Proof Key for Code Exchange) protège l’échange du code d’autorisation contre les interceptions, en particulier sur les clients publics (CLI, desktop apps).

Concrètement, votre serveur expose désormais un Protected Resource Metadata (PRM) :

GET /.well-known/oauth-protected-resource
{
  "resource": "https://mcp.votresociete.fr",
  "authorization_servers": ["https://auth.votresociete.fr"],
  "scopes_supported": ["mcp:read", "mcp:write"],
  "bearer_methods_supported": ["header"]
}

Quand un client MCP appelle votre serveur sans token, il reçoit un 401 qui pointe vers ce PRM. Le client va alors demander un token à votre IdP via PKCE, puis rejoue la requête. Plus aucune clé statique en circulation.

Resource Indicators (RFC 8707)

C’est le point que beaucoup ratent. Sans RFC 8707, un token obtenu pour mcp-github.votresociete.fr peut être rejoué sur mcp-database.votresociete.fr si les deux serveurs partagent le même IdP. Avec RFC 8707, le client doit déclarer la ressource cible :

curl -X POST https://auth.votresociete.fr/token \
  -d grant_type=authorization_code \
  -d resource=https://mcp-github.votresociete.fr \
  -d code_verifier=...

Le token retourné est cryptographiquement scopé à cette ressource. Un serveur malveillant qui intercepte le token ne peut pas l’utiliser ailleurs. C’est exactement la classe d’attaque que la crise de croissance MCP a rendue critique, voir notre analyse MCP en crise de croissance, Perplexity lâche le protocole pour le contexte écosystème.

Dynamic Client Registration et scope incrémental

Deux nouveautés qui simplifient la vie :

• DCR : un nouveau client MCP peut s’enregistrer automatiquement auprès de votre IdP via POST /register. Plus besoin de pré-déclarer chaque agent, chaque IDE, chaque utilisateur.
• Incremental scope consent : au lieu de demander tous les scopes au login, le client demande mcp:read au démarrage, puis mcp:write uniquement quand l’utilisateur déclenche une action d’écriture. Principe du moindre privilège, appliqué.

Selon Clutch Security, 86 % des MCP servers d’entreprise ont implémenté RFC 8707 fin avril 2026. Le côté PME accuse un retard de plusieurs mois.

Les 3 risques concrets d’une clé statique sur un serveur MCP

1. Le leak en logs

Un serveur MCP log par défaut les tool calls. Sans redaction structurée, votre clé GitHub, votre token Supabase, votre password Postgres atterrissent en clair dans /var/log/mcp-server.log. Toute personne avec un accès lecture sur le serveur peut les exfiltrer. Tout système de monitoring qui ingère ces logs (Datadog, Loki, ELK) les indexe.

C’est le scénario du Supabase MCP data leak : un agent IA appelle un tool, la réponse contient une connection string complète, le log la capture, l’IdP n’est jamais averti que le credential a fuité. Pomerium a publié l’autopsie : “When AI Has Root”.

2. L’agent IA qui expose le token

Un LLM ne fait pas la différence entre une donnée métier et un secret. Si vous demandez à votre agent : “Liste les outils que tu peux utiliser et explique comment ils s’authentifient”, il y a une probabilité non nulle qu’il inclue le token dans sa réponse. C’est arrivé. Plusieurs fois.

OAuth résout le problème côté architecture : le serveur ne voit jamais le client secret. L’agent ne reçoit qu’un access token éphémère (15 min - 1 h), scopé à un seul serveur. Même s’il leak, la fenêtre d’exploitation est minuscule.

Pour évaluer si vos agents IA en production sont à risque, notre grille de sécurité agent IA en 10 questions couvre ce point dans la section “secrets et identités”.

3. La rotation impossible

Une clé statique en .env, vous savez quand elle a été créée, vous ne savez jamais où elle est utilisée. Au moment où vous découvrez qu’elle a leaké, vous devez :

1. La régénérer côté provider
2. La redéployer sur chaque serveur, agent, conteneur qui l’utilise
3. Espérer que vous n’en avez oublié aucun

Avec OAuth, votre IdP révoque le refresh token. Tous les access tokens dérivés expirent dans l’heure. Aucun redéploiement. Vous pouvez révoquer 50 clients en une commande SQL.

C’est exactement ce qu’a vécu Vercel lors du breach OAuth supply chain d’avril 2026, et leur capacité à révoquer en bloc a limité la casse. Voir notre analyse Vercel piraté : l’OAuth d’un preneur de notes IA a suffi.

Migration en 4 étapes : inventaire, IdP, implémentation, rotation

Étape 1 : Inventaire (3-5 jours)

Listez tous vos serveurs MCP. Ça paraît évident, c’est rarement fait. Trois sources :

# 1. Serveurs déclarés dans les configs Claude Desktop / Cursor / etc.
find ~ -name "*.mcp*" -o -name "claude_desktop_config.json" 2>/dev/null

# 2. Conteneurs Docker MCP en production
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i mcp

# 3. Clés statiques dans les .env
grep -rE "^(MCP_|.*_MCP_).*TOKEN=" /opt /srv 2>/dev/null

Pour chaque serveur trouvé, documentez : URL d’accès, type d’auth actuel, clients qui l’utilisent, scopes nécessaires. Si vous avez déployé MCP via n8n et son intégration langage naturel, pensez à inventorier aussi les workflows qui appellent vos serveurs.

Étape 2 : Choix de l’IdP (2-3 jours)

IdP	Pour qui	Setup	Coût
Pocket ID	PME < 50 personnes, équipe légère	1 conteneur Docker, passkeys natifs	Gratuit, self-hosted
Keycloak 26.6	Équipes tech-savvy, besoins enterprise	1-2 jours, support CIMD expérimental	Gratuit, self-hosted
Aembit	Cloud-native, multi-cloud	Managed, Infrastructure-Asserted Identity	$$ par workload
Curity	Banque, santé, > 500 employés	Audit-compatible, support entreprise	$$$

Recommandation pour la majorité des PME : Pocket ID si vous avez 1-3 serveurs MCP et < 20 utilisateurs, Keycloak si vous voulez consolider avec votre SSO existant.

Keycloak depuis la 26.6 (avril 2026) supporte CIMD (OAuth Client ID Metadata Document), conforme à la spec MCP 2025-11-25. La doc dédiée keycloak.org/securing-apps/mcp-authz-server est à jour.

Étape 3 : Implémentation OAuth 2.1 + PKCE côté serveur (1-2 semaines)

Trois changements de code minimaux :

a) Exposer le PRM

// server.ts (TypeScript SDK)
app.get("/.well-known/oauth-protected-resource", (_req, res) => {
  res.json({
    resource: "https://mcp.votresociete.fr",
    authorization_servers: ["https://auth.votresociete.fr"],
    scopes_supported: ["mcp:read", "mcp:write"],
    bearer_methods_supported: ["header"]
  });
});

b) Valider le token et le resource indicator

async function validateToken(token: string) {
  const decoded = await jwtVerify(token, JWKS);
  if (decoded.aud !== "https://mcp.votresociete.fr") {
    throw new Error("Token not scoped to this MCP server");
  }
  return decoded;
}

c) Renvoyer un 401 + PRM si pas de token

if (!authHeader) {
  res.set("WWW-Authenticate",
    'Bearer resource_metadata="https://mcp.votresociete.fr/.well-known/oauth-protected-resource"');
  return res.status(401).end();
}

Si vous êtes en Python (FastMCP), la lib mcp-auth (mcp-auth.dev) fait l’essentiel en 20 lignes de boilerplate.

Étape 4 : Rotation et phase-out (1-2 semaines)

Ne coupez jamais brutalement les clés statiques. Pendant 4 à 6 semaines, faites tourner les deux modes en parallèle dans votre middleware :

async function authenticate(req) {
  const auth = req.headers.authorization;
  if (auth?.startsWith("Bearer ")) {
    return validateOAuthToken(auth.substring(7));
  }
  if (auth?.startsWith("ApiKey ")) {
    logDeprecation(req); // alerter, mesurer
    return validateLegacyKey(auth.substring(7));
  }
  return reject401();
}

Mesurez chaque semaine la part d’appels en ApiKey vs Bearer. Quand vous tombez sous 5 % en ApiKey, contactez les derniers clients, fixez une date butoir, et révoquez en bloc côté provider source (GitHub, Supabase, Notion, etc.).

Pocket ID, Keycloak, Aembit : le bon outil pour votre PME

Cas concrets pour fixer les idées.

Cas 1 : start-up B2B SaaS, 12 personnes, 2 serveurs MCP internes (CRM + analytics)

Pocket ID. Un Docker, passkeys, 2 jours de mise en place. Utilisateurs ajoutés via interface admin. Aucun coût récurrent.

Cas 2 : PME 80 personnes, déjà sur Keycloak pour le SSO interne, 5 serveurs MCP

Keycloak 26.6. Activez le module MCP-Authorization (expérimental mais stable). Réutilisez vos realms et groupes existants. Les scopes MCP s’ajoutent comme client scopes classiques. 1 semaine de migration.

Cas 3 : ETI 300 personnes, multi-cloud (AWS + GCP), 10+ serveurs MCP, équipe SRE

Aembit. Managed, intègre les IAM Roles AWS et les Service Accounts K8s sans secret partagé. Tokens éphémères liés au runtime. Coût par workload mais ROI rapide vu le périmètre.

Cas 4 : santé, finance, ou opérateur d’importance vitale

Curity. Hors-scope PME standard, mais c’est l’option avec audit logs structurés et certifications conformité.

L’authentification est une couche. Elle ne remplace pas le sandboxing. Pour la couche d’isolation runtime, notre checklist 48 h MCP 2.4 couvre les 10 points complémentaires (Docker, allowlist de tools, JSON Schema strict).

Calendrier réaliste : 4 à 6 semaines pour un parc de 5 à 10 serveurs

Récapitulatif chronologique typique :

• Semaine 1 : inventaire complet, choix IdP, setup Pocket ID ou Keycloak en environnement de staging
• Semaine 2 : PoC sur le serveur MCP le moins critique, validation du flow PKCE bout en bout
• Semaine 3-4 : déploiement OAuth en production sur tous les serveurs, middleware dual-mode (clé statique + OAuth en parallèle)
• Semaine 5 : monitoring de la part d’appels en mode legacy, communication aux équipes consommatrices
• Semaine 6 : phase-out des clés statiques, révocation côté providers, audit final

Si votre équipe est réduite, étalez sur 8 semaines. Si vous avez plus de 10 serveurs, prévoyez 10 à 12 semaines.

Le coût de ne rien faire est désormais supérieur au coût de migrer. Les nouveaux clients MCP exigeront OAuth dans les six prochains mois. Les audits de sécurité (SOC 2, ISO 27001, NIS2) flaggent les clés statiques en .env comme une non-conformité critique. Et chaque semaine ajoute des chances qu’un de vos secrets parte en log, en transcription, ou en réponse d’agent.

Vous êtes dans la majorité des 53 %. Vous n’y êtes pas obligé longtemps.