Construire MCP ensemble : la contribution d'Arcade à l'authentification sécurisée des agents

C’est l’écart entre la conception de MCP et la réalité en production. Le protocole gère très bien l’authentification client-serveur, mais il manque totalement de mécanisme pour que les serveurs obtiennent des identifiants tiers de façon sécurisée. Chez Arcade.dev, nous travaillons à corriger cette lacune fondamentale.

Le problème technique : le flux de credentials dans les systèmes distribués

Voyons concrètement ce qui se passe. Votre serveur MCP doit effectuer des requêtes authentifiées vers des API externes. Or MCP ne dispose d’aucun mécanisme sécurisé pour collecter des credentials.

Les contournements actuels sont tous des anti-patterns de sécurité pour les systèmes de production multi-utilisateurs :

• Tokens de compte de service avec des scopes excessifs
• Credentials codés en dur dans les configs serveur
• Passage des tokens via le client MCP (violation du principe de moindre privilège)
• Stockage des credentials côté client (bonjour, risques d’exfiltration de tokens)

Ce n’est pas qu’une mauvaise UX : c’est une faille architecturale de sécurité fondamentale. Les clients MCP sont souvent du code non fiable qui s’exécute sur les appareils des utilisateurs. Ce sont des « clients publics » OAuth 2.0 incapables de stocker des secrets de façon sécurisée. Pourtant, c’est exactement ce qu’on force les développeurs à faire aujourd’hui.

Notre parcours d’ingénierie : deux approches de l’authentification sécurisée

PR #475 : Ajouter l’interaction utilisateur comme capacité client

Notre proposition initiale introduisait une nouvelle capacité client pour les interactions utilisateur. L’idée centrale : exploiter le navigateur comme contexte de sécurité de confiance, exactement comme OAuth 2.0 le fait avec succès depuis plus de 15 ans.

L’implémentation a ajouté une capacité userInteraction :

interface UserInteractionRequest {
  method: 'userInteraction';
  params: {
    prompt: string;
    url?: string;
    timeout?: number;
  };
}

Cela permettait aux serveurs de rediriger les utilisateurs vers des endpoints sécurisés pour collecter des credentials, en gardant les données sensibles hors du contexte d’exécution client. La proposition a suscité de larges discussions et un audit de sécurité avec plus de 50 contributeurs analysant les vecteurs d’attaque, les protections CSRF et la gestion d’état.

Mais MCP 2025-06-18 a livré l’élicitation, une capacité client pour afficher dynamiquement des formulaires et collecter des données utilisateur. L’élicitation via formulaires ne fonctionne pas pour les credentials ou données sensibles, mais pouvait-elle être étendue pour permettre des interactions utilisateur sécurisées ?

PR #887 : Étendre l’élicitation avec le mode URL

Plutôt que d’avoir deux capacités client similaires mais distinctes, nous avons fait évoluer notre approche. PR #887 étend le framework d’élicitation avec un nouveau mode :

interface UrlElicitation {
  id: string;
  mode: 'url';
  url: string;
  message: string;
  metadata?: {
    oauth_provider?: string;
    required_scopes?: string[];
    state?: string;
  };
}

Cela crée une séparation claire des responsabilités :

• Mode formulaire : UI rendue côté client pour les données non sensibles (préférences, paramètres)
• Mode URL : Navigation directe dans le navigateur pour les flux sensibles (OAuth 2.0, paiements, WebAuthn, SAML)

Le modèle de sécurité est explicite : l’élicitation par formulaire fait transiter les données par le client, l’élicitation URL court-circuite entièrement le client. Mais pourquoi est-ce important ?

Analyse approfondie : pourquoi l’élicitation URL change la donne

Implémentation OAuth 2.0 correcte

Prenons l’intégration GitHub. Avec l’élicitation URL, vous obtenez un vrai OAuth 2.0 :

# Server initiates OAuth flow
def handle_github_tool_call(params):
    if not has_valid_token(user_id):
        state = generate_secure_state()
        code_verifier = generate_code_verifier()

        auth_url = build_oauth_url(
            client_id=GITHUB_CLIENT_ID,
            redirect_uri=CALLBACK_URL,
            state=state,
            code_challenge=hash_verifier(code_verifier),
            scope="repo:read"
        )

        raise ElicitationRequired([{
            "id": f"github-auth-{state}",
            "mode": "url",
            "url": auth_url,
            "message": "Authorize GitHub access",
            "metadata": {
                "oauth_provider": "github",
                "required_scopes": ["repo:read"]
            }
        }])

Ou autre chose qu’OAuth : une redirection vers un portail de paiement, une page de connexion IDP d’entreprise, etc. Le client se contente d’ouvrir l’URL. Côté client, cela signifie : pas de gestion de token, pas de gestion d’état, aucune responsabilité de sécurité.

Respecter les frontières de sécurité

L’élicitation URL impose des frontières de sécurité appropriées :

1. Client (non fiable) : Facilite la navigation, gère la logique de retry
2. Serveur (fiable) : Gère les tokens, valide l’état, applique les scopes
3. Fournisseur d’auth (fiable) : Gère l’authentification utilisateur, le consentement

Cela reproduit des patterns de sécurité web établis. Le client MCP ne touche jamais aux credentials, ce qui prévient des catégories entières d’attaques :

• Exfiltration de tokens via des clients compromis
• Escalade de scope par manipulation du client
• Le problème du « confused deputy »

Bénéfices concrets de l’implémentation

Résultats de notre recherche sur les serveurs MCP prêts pour la production chez Arcade.dev :

// Before: Insecure token passing
const result = await mcp.callTool('search_gmail', {
  query: 'weekly report',
  token: localStorage.getItem('gmail_token'), // 🚨 Security nightmare
});

// After: Secure URL elicitation
try {
  const result = await mcp.callTool('search_gmail', {
    query: 'weekly report',
  });
} catch (e) {
  if (e.code === 'ELICITATION_REQUIRED') {
    // Client opens URL, user auths, server stores token
    window.open(e.elicitations[0].url);
    // Retry after auth completes
  }
}

Ce pattern reproduit ce que font déjà les applications clientes pour interagir avec des services nécessitant des redirections pour l’autorisation.

Authentification multi-fournisseurs

Les vrais agents ont besoin de plusieurs fournisseurs d’auth. L’élicitation URL gère ça élégamment :

// Server can request multiple authorizations
throw new ElicitationRequired([
  {
    id: 'gmail-auth',
    mode: 'url',
    url: getGoogleOAuthUrl(),
    message: 'Authorize Gmail access',
  },
  {
    id: 'slack-auth',
    mode: 'url',
    url: getSlackOAuthUrl(),
    message: 'Connect Slack workspace',
  },
]);

Ce que ça permet

Avec une autorisation correcte, les serveurs MCP se rapprochent d’une utilisation en production :

• Accès limité : Demander le minimum de permissions nécessaires
• Renouvellement de token : Gérer l’expiration sans intervention utilisateur
• Pistes d’audit : Tracer les actions effectuées avec quelles autorisations
• Révocation : Les utilisateurs peuvent révoquer l’accès à tout moment via le fournisseur

Les fondations techniques comptent. C’est la différence entre une démo et une infrastructure de production.

Calendrier d’implémentation

PR #887 est en cours de revue. Pour les premiers adoptants :

1. Aujourd’hui : Les outils Arcade.dev implémentent déjà ces patterns
2. Court terme : L’élicitation URL standardise l’approche
3. Futur : L’écosystème MCP adopte ces patterns côté clients et serveurs

Vous voulez accélérer le processus ?

• Relire PR #887 et tester le modèle de sécurité en profondeur
• Implémenter l’élicitation URL dans votre serveur MCP

Sans moyen d’interagir de façon sécurisée avec l’utilisateur, MCP reste limité aux serveurs connectés uniquement à des API first-party. En ajoutant un mécanisme qui respecte les frontières de sécurité du client (inspiré des patterns éprouvés d’OAuth), des serveurs MCP plus puissants deviennent possibles, permettant enfin des cas d’usage en production comme les agents IA sécurisés pour les workflows on-call SRE. L’avenir de MCP nous enthousiasme, et vous ?

L’équipe Arcade.dev a passé des années à renforcer l’auth chez Okta, Stormpath et Redis. Nous appliquons ces leçons pour rendre l’infrastructure IA prête pour la production. Découvrez ces principes en action dans notre blueprint pour une alternative sécurisée à OpenClaw avec Arcade et Claude Code.

*Vous voulez construire des agents IA qui fonctionnent vraiment en production ?. En attendant que l’autorisation arrive dans MCP, Arcade implémente déjà une auth sécurisée pour plus de 100 intégrations. Pas de bot tokens, pas de cauchemars de sécurité, juste de vrais flux OAuth qui marchent.*

Commencer à construire avec Arcade → S’inscrire.