Une fois qu’un serveur MCP expose des outils capables de lire et modifier un site WordPress, la question de l’authentification cesse d’être un détail technique pour devenir la première ligne de défense du site. Nous avons vu passer des serveurs MCP configurés avec un unique identifiant administrateur partagé entre tous les outils, une pratique qui fonctionne en démonstration et devient un risque réel dès la mise en production. Cet article ne traite pas de la gouvernance RGPD de ces accès, un sujet distinct : il se concentre sur la mécanique technique de l’authentification elle-même.
Voici comment nous structurons désormais l’authentification d’un serveur MCP connecté à un site WordPress client, avec des périmètres de droits pensés outil par outil.
Pourquoi un compte administrateur partagé est une mauvaise idée
Un unique identifiant administrateur donne au serveur MCP, et donc à tout agent qui s’y connecte, la capacité de tout faire sur le site : supprimer des utilisateurs, modifier les réglages critiques, installer des extensions. Si l’agent se trompe d’action, ou si le serveur MCP lui-même est compromis, les dégâts potentiels sont maximaux. Le principe que nous appliquons systématiquement est celui du moindre privilège : chaque outil du serveur MCP ne doit disposer que des droits strictement nécessaires à sa fonction, jamais plus.
Les jetons d’application, une base solide
WordPress propose nativement les jetons d’application, rattachés à un utilisateur mais révocables individuellement sans affecter les autres. Nous créons un utilisateur dédié par serveur MCP, avec un rôle personnalisé restreint aux capacités réellement utilisées, puis un jeton d’application propre à ce serveur, jamais réutilisé ailleurs. Si le jeton doit être révoqué suite à un doute de sécurité, seule cette intégration est coupée, sans effet sur le reste du site.
OAuth pour les connexions côté client final
Quand le serveur MCP doit agir au nom d’un utilisateur final, plutôt qu’au nom d’un compte de service unique, un jeton d’application fixe ne suffit plus : il faut un flux OAuth complet, avec autorisation explicite de l’utilisateur et jeton limité dans le temps. Le protocole MCP s’appuie sur les mécanismes OAuth 2.1 standards pour cet usage, le serveur MCP jouant le rôle de client OAuth face à WordPress comme fournisseur d’identité, via une extension dédiée à la gestion des autorisations.
// Exemple de vérification de périmètre avant exécution d'un outil MCP
function verifier_perimetre_outil( string $outil, WP_User $utilisateur ): bool {
$perimetres_autorises = array(
'lister_articles' => array( 'edit_posts' ),
'creer_brouillon' => array( 'edit_posts' ),
'publier_article' => array( 'publish_posts' ),
'supprimer_article' => array( 'delete_posts', 'manage_options' ),
);
if ( ! isset( $perimetres_autorises[ $outil ] ) ) {
return false;
}
foreach ( $perimetres_autorises[ $outil ] as $capacite ) {
if ( ! user_can( $utilisateur, $capacite ) ) {
return false;
}
}
return true;
}
Un périmètre différent par outil, pas par serveur
Le point le plus souvent négligé : la granularité doit descendre jusqu’à l’outil, pas s’arrêter au niveau du serveur MCP dans son ensemble. Un serveur qui expose à la fois la lecture d’articles et leur suppression ne doit pas donner les deux droits au même jeton par simplicité de configuration. Sur un projet client, nous avons ainsi séparé les jetons de lecture, largement diffusés à plusieurs agents internes, des jetons de modification, réservés à un unique agent supervisé.
Ce qu’il faut journaliser
Chaque appel d’outil authentifié doit laisser une trace exploitable : l’identifiant du jeton utilisé, l’outil appelé, les paramètres transmis et le résultat de la vérification de périmètre. En cas d’incident, cette journalisation permet de savoir précisément quel jeton a été utilisé pour quelle action, sans avoir à deviner à partir des seuls journaux WordPress standards.
- Un utilisateur et un jeton dédiés par serveur MCP, jamais un compte partagé
- Des rôles personnalisés limités aux capacités réellement nécessaires
- OAuth pour toute action effectuée au nom d’un utilisateur final
- Une journalisation systématique des appels avec le jeton utilisé
Le principe du moindre privilège coûte un peu de temps de configuration au départ. Il coûte beaucoup moins cher qu’un incident de sécurité découvert après coup.
En résumé
Authentifier un serveur MCP correctement ne relève pas d’une technologie exotique : ce sont les mécanismes WordPress existants, jetons d’application et OAuth, appliqués avec une granularité fine, outil par outil. La discipline à tenir est organisationnelle autant que technique : résister à la tentation du compte unique qui simplifie la configuration au prix d’un risque disproportionné.
