# Authentifier un serveur MCP WordPress : OAuth, jetons et périmètres

> Mettre en place l'authentification technique d'un serveur MCP connecté à WordPress, avec des droits restreints outil par outil plutôt qu'un accès global.

- Auteur : Clément Hadrot
- Publié le : 2025-12-15
- Mis à jour le : 2025-12-15
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/authentifier-serveur-mcp-oauth/

## L’essentiel

- Un serveur MCP ne doit jamais partager un compte administrateur unique
- Chaque outil mérite son propre périmètre de droits
- Un jeton doit pouvoir être révoqué sans casser tout le reste

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.

> L'essentiel à retenir : Un serveur MCP ne doit jamais partager un compte administrateur unique ; Chaque outil mérite son propre périmètre de droits ; Un jeton doit pouvoir être révoqué sans casser tout le reste

## 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é.