Protéger l’accès MCP de Composer avec Cognito OAuth

Composer peut protéger son endpoint MCP avec des access tokens Amazon Cognito tout en utilisant les hooks de transport de l’adaptateur MCP WordPress officiel. Il ne remplace pas l’adaptateur et ne crée pas d’utilisateur WordPress fantôme pour chaque principal externe.

L’autorisation est l’intersection au moindre privilège entre :

  1. le rôle Composer issu du groupe Cognito du token ;
  2. le rôle maximal autorisé pour l’OAuth App Client ;
  3. les scopes Composer réellement accordés dans l’access token ;
  4. Site Contract, Blueprint, propriété, validation et approbation humaine.

Modes d’accès

  • Open conserve le chemin compatible authentifié par WordPress.
  • Protected valide Cognito lorsqu’un bearer token est présent et peut conserver le chemin de compatibilité configuré.
  • Protected Required échoue fermé : sans provider, mapping des groupes et client autorisé complets, aucun outil n’est exposé ; chaque requête exige un token.

Choisissez le mode dans le Site Contract et MCP Access. N’activez Protected Required qu’après avoir testé le cycle OAuth complet.

Identity provider

Composer peut résoudre la région AWS et l’ID du User Pool depuis un autre composant WP Suite. L’administration affiche région, pool, issuer, URL JWKS, source et état effectifs. Si la résolution manque ou est erronée, activez la configuration manuelle et saisissez les deux valeurs.

AWS Region: eu-central-1
User Pool ID: eu-central-1_AbCd1234
Issuer: https://cognito-idp.eu-central-1.amazonaws.com/eu-central-1_AbCd1234

Ces identifiants ne sont pas secrets. Client secrets et clés privées n’ont pas leur place dans Composer.

Domaine Cognito et App Client public

OAuth nécessite un domaine de User Pool. Choisissez un préfixe Cognito généré ou un custom domain avec certificat ACM et DNS. Créer seulement un App Client ne suffit pas : sans domaine, aucun endpoint Hosted UI n’existe.

Créez un App Client public dédié avec :

  • authorization code grant ;
  • PKCE S256 ;
  • aucun client secret ;
  • l’URL HTTPS de callback exacte fournie par le client MCP ;
  • openid et les scopes du resource server Composer ;
  • les refresh tokens si le client en a besoin.

WP Suite orchestration v1.0.93 ou ultérieur peut créer facultativement resource server et App Client pour un User Pool nouveau ou existant. Pour un nouveau pool, le deployment wizard exige aussi un domaine Cognito généré ou personnalisé. Un pool existant géré séparément peut conserver son domaine externe. Copiez l’output AgentComposerMcpOAuthClientId du stack dans le mapping des clients OAuth de Composer.

La callback doit correspondre exactement, chemin et slash final compris.

Groupes, rôles, clients et scopes

Mappez les valeurs exactes de cognito:groups aux rôles Composer. Avec plusieurs groupes, le rôle mappé le plus élevé sert de départ. Ajoutez chaque App Client autorisé avec libellé local et rôle maximal ; ce plafond ne peut que réduire le rôle.

Scopes OAuth pris en charge :

openid
composer/read
composer/draft
composer/propose
composer/publish.request

Composer normalise les scopes du resource server vers composer.read, composer.draft, composer.propose et composer.publish.request. Un déploiement legacy peut aussi dériver sc.group.<group>. La claim signée cognito:groups reste la source de l’appartenance ; un scope n’invente pas un groupe.

Dans le flux Cognito legacy testé, demander openid était nécessaire pour le chemin de claims voulu. Cela n’oblige pas à activer l’OIDC email/domain claiming de ChatGPT. Composer valide l’access token signé, pas l’ID token, et ne publie pas de document OIDC proxy dont l’issuer serait invalide.

Discovery public avant authentification

Les métadonnées protected resource MCP, authorization server OAuth et le défi 401 WWW-Authenticate doivent être accessibles sans bearer token. Sinon, le client ne peut pas découvrir comment s’authentifier.

Cela doit fonctionner en HTTP direct sur /wp-json/mcp/smartcloud-agent-composer et via un profil HTTP OpenAI Secure MCP Tunnel ciblant le même endpoint. Un ancien profil STDIO ne transporte ni le défi HTTP externe ni le bearer token. Sauvegardez et migrez chaque site vers HTTP, redémarrez son service et vérifiez la discovery avant de reconnecter.

Configurer ChatGPT

  1. Dans l’app en mode développeur, choisissez le tunnel du bon site ou l’URL directe.
  2. Dans Advanced OAuth settings, choisissez un client OAuth public défini par l’utilisateur.
  3. Copiez exactement la callback ChatGPT dans l’App Client Cognito.
  4. Saisissez le Client ID, laissez le secret vide et l’auth endpoint sur none.
  5. Demandez openid et les scopes Composer nécessaires au workflow.
  6. Terminez le login et le consentement Cognito Hosted UI.
  7. Reconnectez, vérifiez le catalogue d’actions et testez d’abord une lecture.

401 contre 403

  • 401 Authentication required : token absent, invalide ou expiré, mauvais issuer/audience/client, ou vérification impossible.
  • 403 Forbidden : authentification réussie, mais groupe, plafond client, scope, rôle, propriété ou Site Contract interdit l’outil.

Ne corrigez pas cela en accordant Administrator WordPress ou en désactivant le contrat. Consultez les détails expurgés dans Audit & portability.

Audit et sécurité des tokens

Composer inscrit décisions, appels terminés, identité externe, résultat et codes expurgés dans une chaîne d’audit détectant les altérations. L’interface affiche l’heure locale du navigateur et sa zone ; le détail conserve l’UTC exact.

Le bearer token complet, l’Authorization header, le client secret, les arguments de requête et le résultat d’un outil ne doivent jamais être stockés ou affichés.

Liste de production

  • Région, pool, issuer et URL JWKS résolus sont corrects.
  • Le domaine généré/custom sert la Hosted UI.
  • Le client public utilise code + PKCE S256 et la callback exacte.
  • Les groupes requis figurent dans l’access token et sont mappés exactement.
  • Client ID, rôle maximal et scopes Composer autorisés sont corrects.
  • Les clients inconnus échouent selon la policy.
  • Discovery fonctionne sans bearer sur la route HTTP choisie.
  • Les limites Reader, Contributor et Publisher sont testées séparément.
  • Publisher peut demander une approbation mais ne publie pas directement.
  • Succès et refus apparaissent dans l’audit sans données sensibles.

Pour le transport, continuez avec MCP direct ou Secure Tunnel et ChatGPT.