Une intégration MCP peut fonctionner parfaitement sur le poste d’un développeur tout en étant inadaptée à un déploiement en entreprise.
Pourquoi ?
Parce qu’un prototype répond principalement à une question :
Est-ce que la connexion fonctionne ?
Une intégration de production doit répondre à beaucoup d’autres questions :
- sous quelle identité Claude accède-t-il au service ?
- cette identité est-elle auditable ?
- quelles données peut-elle consulter ?
- où les credentials sont-ils stockés ?
- comment sont-ils renouvelés ?
- les accès respectent-ils le principe du
least privilege? - les actions sont-elles journalisées ?
- un administrateur peut-il verrouiller la configuration ?
- où les données sont-elles traitées ?
L’authentification ne doit donc pas être ajoutée après coup.
Elle fait partie de l’architecture de l’intégration.
Du prototype à l’intégration enterprise
Prenons une intégration MCP permettant à Claude d’accéder à un service interne.
Pendant le développement, l’objectif peut être simplement :
Claude Code
↓
MCP server
↓
Service interne
Si la connexion fonctionne, le prototype remplit son objectif.
Mais en production, cette architecture soulève immédiatement une question supplémentaire :
Claude Code
↓
MCP server
↓
??? identité ???
↓
Service interne
Le système cible doit savoir qui effectue la requête.
Et cette identité doit correspondre au modèle d’autorisation du service.
Première question : qui est Claude lorsqu’il agit ?
C’est une question essentielle pour comprendre l’authentification MCP en entreprise :
Who is the model acting as?
Claude peut accéder à un service :
- au nom d’un utilisateur ;
- au nom d’un service technique ;
- ou à une ressource locale en utilisant les permissions de l’environnement.
Ces scénarios nécessitent des mécanismes différents.
Le document distingue trois grandes situations :
| Type de service | Authentification |
|---|---|
| Remote avec user identity | OAuth |
| Remote avec service identity | API key via environment variable |
| Local | File-system permissions |
Le bon mécanisme dépend donc du modèle d’identité du service.
Cas 1 : service distant avec identité utilisateur
Imaginons un service SaaS auquel plusieurs utilisateurs accèdent avec des permissions différentes.
Alice peut avoir accès à certaines données.
Bob à d’autres.
Claude doit agir au nom de l’utilisateur connecté.
On obtient :
Utilisateur
↓
Claude
↓
MCP server
↓
Service SaaS
L’identité utilisateur fait partie de la décision d’autorisation.
Dans ce scénario, le document recommande OAuth.
Pourquoi OAuth ?
OAuth permet à l’utilisateur d’autoriser l’accès sans avoir à copier manuellement un secret dans un fichier de configuration.
Le flux présenté dans le module suit ce principe :
Claude / MCP client
↓
MCP server
↓
401 Unauthorized
↓
authentification nécessaire
↓
browser-based sign-in
↓
utilisateur autorise l'accès
↓
token émis
↓
connexion autorisée
Le 401 Unauthorized indique au client qu’une authentification est nécessaire.
Le client peut alors déclencher le processus de connexion.
L’utilisateur s’authentifie et approuve l’accès.
Un token est ensuite délivré et stocké.
L’avantage : personne ne copie le secret à la main
C’est une différence importante avec un système dans lequel l’utilisateur devrait récupérer une clé puis la copier dans un fichier.
Avec OAuth, le processus d’autorisation fournit le token.
Le document présente ce mécanisme comme le pattern attendu pour :
- les cloud services ;
- les SaaS tools ;
- les intégrations où l’identité utilisateur fait partie du modèle d’autorisation.
Le serveur MCP Linear évoqué dans le module utilise ce type de pattern.
OAuth ne signifie pas « pas de secret »
OAuth évite que l’utilisateur manipule directement un credential statique pour chaque connexion.
Mais des tokens existent toujours.
Ils doivent eux aussi être protégés.
Le principe général reste donc valable :
Un credential ne doit pas voyager avec la configuration qui le référence.
L’authentification et la gestion du secret sont deux problèmes liés mais distincts.
Cas 2 : service distant avec service identity
Deuxième situation : Claude doit accéder à une API interne non pas au nom d’un utilisateur, mais au nom d’un service.
Par exemple :
Claude Code
↓
MCP server
↓
Data Warehouse API
L’entreprise peut utiliser un service account disposant d’une API key.
Le modèle devient :
Claude
↓
service identity
↓
API key
↓
service interne
Dans ce scénario, le document indique :
API key in environment variable
Le point important n’est pas seulement l’utilisation d’une API key.
C’est également l’endroit où elle est stockée.
Une API key ne doit pas être dans .mcp.json
La mauvaise configuration serait :
{
"type": "http",
"url": "https://warehouse.internal/mcp",
"headers": {
"Authorization": "Bearer sk-prod-warehouse-abc123"
}
}
Cette configuration couple :
configuration
+
credential
Si .mcp.json est partagé ou commité, la clé voyage avec lui.
La configuration correcte sépare les deux :
{
"type": "http",
"url": "https://warehouse.internal/mcp",
"headers": {
"Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}"
}
}
Puis l’environnement fournit la valeur réelle de :
WAREHOUSE_MCP_TOKEN
Cas 3 : service local
Toutes les intégrations ne nécessitent pas un mécanisme OAuth ou une API key.
Un MCP server peut travailler directement avec des ressources locales.
Par exemple :
Claude Code
↓
MCP server local
↓
File system
Dans ce cas, le document associe le contrôle d’accès aux file-system permissions.
Des deny rules peuvent également limiter les chemins accessibles.
L’objectif reste le même :
permettre uniquement les accès nécessaires à la tâche.
Trois scénarios, trois modèles
On peut résumer le raisonnement ainsi :
SERVICE DISTANT
+
IDENTITÉ UTILISATEUR
↓
OAuth
SERVICE DISTANT
+
IDENTITÉ TECHNIQUE
↓
API key / service credential
↓
environment variable
SERVICE LOCAL
↓
file-system permissions
+
deny rules
Il faut donc éviter de choisir un mécanisme d’authentification simplement parce qu’il est familier.
La première question est :
Quel modèle d’identité le système cible utilise-t-il ?
Le principe du least privilege
Une fois l’identité déterminée, il faut encore définir ses permissions.
Le document insiste sur le fait que chaque credential doit être limité au narrowest access its task needs.
C’est le principe du :
least privilege
Prenons un MCP server qui doit uniquement consulter certaines informations dans un data warehouse.
Il n’a probablement pas besoin de pouvoir :
- supprimer des tables ;
- modifier les utilisateurs ;
- changer les permissions ;
- administrer l’ensemble du warehouse.
Son identité devrait disposer uniquement des droits nécessaires.
Pourquoi le least privilege est important
Imaginons deux credentials.
Credential A
→ accès administrateur complet
Credential B
→ lecture sur les données nécessaires
Les deux permettent peut-être au tool MCP d’effectuer sa tâche.
Mais leur niveau de risque est très différent.
Si le credential B est compromis :
Blast radius
↓
accès limité
Si le credential A est compromis :
Blast radius
↓
potentiellement très important
La sécurité ne consiste donc pas seulement à protéger les credentials.
Il faut également limiter ce qu’ils permettent de faire.
Authentification et secret management sont deux décisions
Il est utile de séparer deux questions.
Question 1
Comment prouver l’identité ?
Exemples :
OAuth
API key
file-system identity
Question 2
Comment protéger le credential associé ?
Exemples :
OAuth token storage
environment variable
secret store
Une bonne méthode d’authentification peut être mal implémentée si les credentials sont ensuite stockés au mauvais endroit.
C’est précisément ce qu’illustre le cas de la clé MCP commitée étudié précédemment.
Les trois pratiques de gestion des secrets
Le module structure la gestion des credentials autour de trois pratiques.
1. Separation
Le credential reste séparé de la configuration.
configuration
↓
référence
↓
secret externe
2. Storage
Le secret est placé dans un emplacement adapté.
Pour une utilisation locale ou un pipeline :
environment variable
Pour un secret partagé ou devant être audité :
managed secret store
3. Rotation
Le credential peut être remplacé sans modifier le code qui le référence.
Ces trois mécanismes doivent accompagner le choix de l’authentification.
Une intégration enterprise doit être auditable
Dans un environnement réglementé, savoir que l’accès est authentifié ne suffit pas.
Il faut également pouvoir répondre à :
Quelles actions ont été effectuées ?
Le document propose l’utilisation d’un PostToolUse hook pour journaliser les tool calls.
Le modèle devient :
Claude
↓
tool call
↓
exécution
↓
PostToolUse hook
↓
audit store
Le hook peut enregistrer les opérations et leurs paramètres dans un système d’audit.
Pourquoi utiliser un hook pour l’audit ?
On pourrait demander à Claude :
« Enregistre toutes tes actions dans le système d’audit. »
Mais cela placerait l’audit sous le contrôle du comportement du modèle.
Le document privilégie une approche déterministe.
Le PostToolUse hook s’exécute à chaque événement correspondant.
L’agent ne décide donc pas si une action doit être journalisée ou non.
On retrouve une distinction importante :
Instruction au modèle
↓
comportement attendu
contre :
Hook
↓
comportement imposé
Pour une exigence d’audit, le second mécanisme apporte la garantie recherchée.
L’administrateur doit parfois pouvoir verrouiller la configuration
Une entreprise réglementée peut également poser cette question :
Un développeur peut-il modifier lui-même la configuration d’authentification ?
Dans certains environnements, la réponse doit être non.
L’organisation doit pouvoir imposer :
- les MCP servers autorisés ;
- les règles d’accès ;
- les mécanismes d’authentification ;
- certaines politiques de sécurité.
Le document associe ce besoin aux enterprise managed settings.
L’architecture devient :
Administrateur
↓
managed configuration
↓
Claude Code
↓
MCP server
Le setup ne dépend plus de la configuration individuelle de chaque développeur.
Pourquoi cela compte en environnement réglementé
Prenons un audit.
Le responsable sécurité demande :
« Comment garantissez-vous que tous les développeurs utilisent le même mécanisme d’authentification ? »
Une réponse comme :
« Nous leur demandons de configurer correctement leur fichier local »
est beaucoup moins robuste qu’un contrôle administré centralement.
Les enterprise managed settings permettent d’apporter une réponse organisationnelle et technique à ce besoin.
La question de la data residency
Une autre exigence peut concerner l’endroit où les données sont traitées.
Le document évoque la data residency comme l’une des questions supplémentaires posées dans les environnements réglementés.
L’architecture doit permettre de répondre à :
Où les données vont-elles ?
Le module associe cette exigence à :
- un endpoint HTTP situé dans la région appropriée ;
- une plateforme de déploiement configurée pour maintenir le traitement dans cette région.
Le point essentiel n’est pas seulement technique.
Lors d’un audit, l’entreprise doit pouvoir fournir une réponse vérifiable concernant le chemin suivi par les données.
Le tableau de décision du module
Le document fournit une synthèse particulièrement utile.
| Service type | Auth method | Secrets | Logging | Configuration |
|---|---|---|---|---|
| Remote + user identity | OAuth | Token issu du provider | PostToolUse | Enterprise managed settings |
| Remote + service identity | API key | Environment variable | PostToolUse | Enterprise managed settings |
| Local | File-system permissions | Pas nécessairement de credential | PostToolUse | Deny rules / managed settings |
Ce tableau révèle que l’authentification n’est qu’une colonne de l’architecture.
Il faut également penser :
Identity
+
Secret storage
+
Logging
+
Configuration control
Diagnostiquer une erreur d’authentification
Le fichier fournit également cet exemple de trace :
[MCP Client] Connecting to https://data-api.internal/mcp ...
[MCP Client] GET /auth/token, 401 Unauthorized
[MCP Client] Reading credential from:
/home/jenkins/.config/mcp-credentials.json
[MCP Client] Credential value:
WAREHOUSE_TOKEN=sk-****[redacted]
[MCP Client] Retrying with credential, 401 Unauthorized
[MCP Client] Connection failed after 3 attempts
Trois corrections sont proposées.
A
Faire une rotation de la clé et écrire la nouvelle valeur dans le même fichier.
B
Faire une rotation de la clé, supprimer le credential du fichier, l’injecter comme environment variable dans le CI runner et modifier la configuration MCP pour référencer cette variable.
C
Remplacer l’API key par OAuth.
La meilleure réponse dans le contexte du module est B.
Pourquoi pas simplement OAuth ?
C’est un piège de raisonnement intéressant.
OAuth est une bonne solution lorsque l’on travaille avec une user identity.
Mais rien dans cette trace n’indique qu’il faille changer le modèle d’identité du service.
Le problème observé est :
credential rejeté
+
credential stocké dans un fichier
La correction ciblée consiste donc à :
rotation
+
suppression du credential du fichier
+
injection par environment variable
Changer complètement de mécanisme d’authentification ne répondrait pas directement au problème identifié.
Production : identifier les exigences avant le déploiement
Le module insiste sur une idée importante :
Les problèmes enterprise sont particulièrement coûteux lorsqu’ils sont découverts au moment de la security review.
Un prototype peut fonctionner avec :
connexion
+
credential
Une intégration enterprise peut devoir répondre à :
Identity
+
Authentication
+
Least privilege
+
Secret management
+
Rotation
+
Audit logging
+
Configuration control
+
Data residency
Ces exigences doivent être identifiées pendant la conception.
Pas après le déploiement.
Cost, complexity et risk
Le module présente également les compromis associés à ces mécanismes.
Cost
OAuth ajoute une étape initiale de configuration par utilisateur et par service.
La gestion des API keys implique un processus de rotation.
Les hooks d’audit ajoutent un faible overhead aux tool calls.
Complexity
Les environnements réglementés ajoutent des exigences qui ne sont généralement pas présentes dans un prototype.
Les identifier tôt permet d’éviter qu’elles deviennent des blocages tardifs.
Risk
Le risque devient particulièrement important lorsqu’un prototype passe en production avec :
- credentials hardcodés ;
- absence d’audit ;
- configuration non verrouillable.
Une telle intégration peut échouer lors d’une security review même si elle fonctionne parfaitement sur le plan technique.
Faut-il appliquer tout cela à un prototype ?
Pas nécessairement.
Le document distingue explicitement les besoins d’une intégration de production de ceux d’une démonstration.
Un proof of concept qui n’accède jamais à des données de production ne nécessite pas forcément toute l’infrastructure enterprise.
Mais certaines pratiques ont un coût suffisamment faible pour être utilisées dès le début.
En particulier :
Ne jamais hardcoder les credentials dans les fichiers de configuration.
Utiliser une environment variable dès le prototype évite de devoir corriger cette dette de sécurité plus tard.
Une méthode de raisonnement pour l’examen
Face à un scénario d’authentification MCP, posez les questions dans cet ordre.
1. Quelle identité doit agir ?
User identity ?
Service identity ?
Local identity ?
2. Quel mécanisme correspond à cette identité ?
User identity
→ OAuth
Service identity
→ service credential
Local resource
→ local permissions
3. Où vit le credential ?
Jamais inline dans la configuration
Local / pipeline
→ environment variable
Partagé / auditable
→ secret store
4. Quels droits possède cette identité ?
Appliquer :
least privilege
5. Les actions doivent-elles être auditées ?
Si oui, utiliser un mécanisme déterministe tel qu’un PostToolUse hook selon le modèle présenté dans le module.
6. L’utilisateur peut-il modifier la configuration ?
Si l’organisation doit la contrôler :
enterprise managed settings
7. Existe-t-il une contrainte de localisation des données ?
Vérifier les exigences de :
data residency
Ce qu’il faut retenir pour la certification
Remote service + user identity
Pensez :
OAuth
L’utilisateur s’authentifie et autorise l’accès.
Remote service + service identity
Pensez :
API key ou service credential séparé de la configuration.
Dans le scénario du module :
API key
↓
environment variable
Service local
Pensez :
file-system permissions + restrictions d’accès adaptées.
Credential exposé
Pensez :
rotation immédiate.
Un credential exposé ne redevient pas secret.
Audit obligatoire
Pensez :
contrôle déterministe, par exemple PostToolUse pour journaliser les tool calls selon l’architecture du module.
Configuration imposée par l’entreprise
Pensez :
enterprise managed settings.
Piège d’examen
Un piège fréquent consiste à sélectionner la technologie considérée comme la plus sophistiquée au lieu de celle qui correspond au problème.
Par exemple :
API key rejetée
+
secret stocké dans un fichier
ne signifie pas automatiquement :
→ passer à OAuth
Il faut d’abord identifier le modèle d’identité.
Si le service utilise légitimement une service identity, la correction peut être :
rotate credential
+
environment variable
+
least privilege
La bonne architecture est celle qui résout le problème identifié avec le mécanisme adapté au contexte.
Conclusion
Une intégration MCP enterprise ne se résume pas à connecter Claude à une API.
Elle doit établir une chaîne de confiance complète :
Utilisateur / Service
↓
Identity
↓
Authentication
↓
Authorization
↓
MCP server
↓
System
↓
Audit
À cette chaîne s’ajoutent :
Secret management
+
Rotation
+
Least privilege
+
Configuration control
+
Data residency
La règle de raisonnement essentielle est donc :
Commencer par l’identité, choisir ensuite le mécanisme d’authentification, puis sécuriser le credential et contrôler ce que cette identité est autorisée à faire.
C’est ce qui sépare une connexion qui fonctionne d’une intégration prête à être déployée dans un environnement d’entreprise.
Dans la suite de la série
Secrets et credentials : separation, storage et rotation
Nous approfondirons les trois mécanismes qui structurent le cycle de vie d’un secret : pourquoi la configuration et le credential doivent rester séparés, quand choisir une environment variable ou un secret store, et comment concevoir une rotation qui ne casse pas les services consommateurs.
