Démarrer

Authentification

En mode stdio (le défaut), acf-mcp n’a pas d’authentification — le client local est la frontière de confiance. En mode HTTP, vous apportez votre propre passerelle d’authentification. La signature Ed25519 du pied de page est le mécanisme de confiance de la SORTIE, pas de l’appel.

iNote

La signature de doctrine prouve que ce que le serveur a produitn’a pas été altéré. Elle ne prouve pas que l’appel est légitime. Pour cela, utilisez stdio (local) ou une passerelle HTTP authentifiée.

Mode stdio (local)

Le transport par défaut. Le client MCP lance le binaire acf-mcp comme processus enfant et lui parle via stdin/stdout. Il n’y a pas d’authentification parce qu’il n’y a pas de réseau : seul un processus qui a déjà accès au shell de l’utilisateur peut atteindre le serveur. Le modèle de confiance est celui du système d’exploitation.

C’est le mode recommandé pour les déploiements mono-utilisateur (un développeur, un client IA, une machine).

Mode HTTP (multi-utilisateurs)

Le transport HTTP est opt-in (cf. configuration). Il expose un endpoint MCP-over-HTTP, conçu pour être placé derrière votre propre passerelle d’authentification. Le serveur lui-même n’embarque actuellement pas de magasin de clés — vous apportez le vôtre.

En-tête Authorization: Bearer

L’usage attendu, conforme aux pratiques MCP-over-HTTP, est de transmettre une clé API dans l’en-tête Authorization.

http

POST /mcp HTTP/1.1
Host: acf.internal.example.com:3000
Authorization: Bearer acfk_4f9b2c8e1d6a3b7f0c5d8e2a9b4c7f1d
Content-Type: application/json

{ "jsonrpc": "2.0", "method": "tools/call", "params": { ... } }

Votre passerelle, vos clés

L’approche officiellement supportée aujourd’hui : placez un reverse-proxy authentifié (Caddy, nginx, Cloudflare Access, Tailscale, etc.) devant acf-mcp HTTP et terminez l’authentification là. Le serveur n’a aucune notion d’utilisateur ; il fait juste son travail déterministe et signe la sortie.

Caddyfilecaddyfile

# Example: a thin Caddy reverse proxy in front of acf-mcp HTTP
acf.internal.example.com {
  @authed header Authorization "Bearer {env.ACF_INTERNAL_KEY}"
  handle @authed {
    reverse_proxy 127.0.0.1:3000
  }
  respond 401
}

Génération de clés intégrée (prévue)

Une commande npx acf-mcp keygen est planifiée pour émettre des clés API au format acfk_…, persistées localement, vérifiables sans dépendance externe. En attendant, votre passerelle (au-dessus) reste le point d’entrée d’authentification.

Limites de débit

En mode HTTP, le serveur applique un rate-limit par défaut de 60 appels par minute et par IP. C’est une protection minimale contre les boucles d’agents mal cadrées ; ce n’est pas une stratégie anti-DDoS. Placez un WAF ou Cloudflare devant pour un trafic exposé sur l’internet public.

La signature reste la racine de confiance

Quel que soit le transport, chaque sortie embarque doctrine_hash, doctrine_signature et doctrine_public_key. Un consommateur en aval peut donc valider l’authenticité de la doctrine et son intégrité même s’il ne fait pas confiance au transport. Voir signatures de doctrine.