Authentification des serveurs MCP
Configurez la façon dont Scrydon s'authentifie auprès d'un serveur MCP distant — en-têtes statiques, clé API / jeton Bearer, ou OAuth 2.1 (identifiants client et flux utilisateur délégués).
Lorsque vous enregistrez un serveur MCP distant (Streamable HTTP) dans Org Settings → MCP, vous choisissez la façon dont Scrydon s'authentifie auprès de lui. Les modes se configurent par serveur, sur l'entrée du registre.
Exigences relatives à l'URL du serveur
Par défaut, l'URL d'un serveur MCP distant doit être en https:// et se résoudre vers une adresse publique. Scrydon rejette http://, localhost et les plages d'adresses IP privées/réservées, aussi bien à l'enregistrement qu'à la connexion, afin d'éviter qu'un serveur enregistré ne devienne un vecteur de falsification de requête côté serveur (SSRF) vers l'infrastructure interne.
Serveurs auto-hébergés / locaux (http:// et IP privées)
Si vous exécutez un serveur MCP sur votre propre réseau sans TLS — par exemple http://localhost:3000/mcp ou http://192.168.1.20/mcp — activez Allow private networks dans la politique de gouvernance des flux sortants de l'organisation (Platform Settings → Governance → Egress). Il s'agit du même contrôle qui détermine si les exécuteurs d'IA hébergés localement (Ollama, LM Studio, vLLM) peuvent être joints. Lorsqu'il est activé :
- les URL
http://et les cibles loopback / RFC1918 (10.x, 172.16–31.x, 192.168.x) / IPv6 ULA sont autorisées pour les serveurs MCP ; - les points de terminaison de métadonnées cloud (par ex.
169.254.169.254,metadata.google.internal) et les ports de services internes (bases de données, Redis, SSH, …) restent bloqués dans tous les cas.
Lorsque Allow private networks est désactivé (ou qu'aucune politique de flux sortants n'a été enregistrée), le trafic MCP reste en HTTPS et limité aux adresses publiques — le paramètre est fermé par défaut : il doit donc être explicitement activé et enregistré. La modification s'applique aussi bien à l'enregistrement (inscription/approbation d'un serveur) qu'à la sonde Test Connection et à la connexion en direct.
Le HTTP simple n'offre aucun chiffrement du transport — tout jeton bearer ou en-tête que vous configurez circule en clair — n'utilisez-le donc qu'au sein d'un réseau de confiance.
Modes d'authentification
| Mode | Quand l'utiliser |
|---|---|
| Enterprise-managed (OAuth 2.1 / ID-JAG) | Recommandé pour les entreprises. Le fournisseur d'identité de votre organisation (par ex. Okta) détermine quels employés peuvent accéder au serveur — de manière centralisée, avec une seule politique et une seule piste d'audit. Aucune demande d'autorisation par serveur ou par utilisateur. Voir Autorisation gérée par l'entreprise ci-dessous. |
| None / static header | Le serveur est ouvert, ou accepte un jeton de longue durée que vous collez dans un en-tête. Les en-têtes sont configurés par espace de travail lors de l'installation du serveur. C'est le mode par défaut, qui préserve le comportement d'origine. |
| API key / Bearer token | Le serveur s'authentifie avec un jeton statique ou une clé API envoyés dans un en-tête — par ex. Authorization: Bearer <token>. Scrydon lit le jeton dans un secret d'espace de travail au moment de la connexion. Voir Clé API / jeton Bearer ci-dessous. |
| OAuth — client credentials | Accès de service à service pour les serveurs protégés par OAuth qui ne prennent pas (encore) en charge l'authentification gérée par l'entreprise. Scrydon obtient et renouvelle automatiquement un jeton d'accès à l'aide de l'octroi client-credentials d'OAuth 2.1. |
| OAuth — user (delegated) | Accès par utilisateur, lorsque la connexion doit s'exécuter en tant qu'utilisateur final. Nécessite de se connecter depuis l'espace de travail avant que les outils puissent s'exécuter. |
Autorisation gérée par l'entreprise (recommandé)
L'autorisation gérée par l'entreprise (l'extension MCP io.modelcontextprotocol/enterprise-managed-authorization) permet à votre fournisseur d'identité de décider qui peut utiliser chaque serveur MCP — de la même façon qu'il régit déjà la messagerie et les autres applications de l'entreprise. Les employés se connectent une seule fois via le SSO de l'entreprise ; l'accès est accordé ou refusé par la politique de l'IdP, sans écran de consentement par serveur. L'intégration et le départ des collaborateurs se gèrent en un seul endroit.
Fonctionnement. Lorsqu'un utilisateur connecté invoque le serveur, Scrydon échange l'identité IdP de cet utilisateur contre un ID-JAG (assertion d'identité) de courte durée auprès de votre IdP, puis l'échange contre un jeton d'accès MCP auprès du serveur d'autorisation du serveur. Si l'utilisateur n'est pas autorisé, l'IdP refuse et Scrydon ne reçoit jamais de jeton.
Configuration (Org Settings → MCP → Add/Edit server → Authentication → Enterprise-managed) :
| Champ | Description |
|---|---|
| Resource (RFC 8707) | L'identifiant de ressource du serveur MCP — l'audience que votre IdP inscrit dans l'ID-JAG. |
| MCP authorization-server token URL | L'endroit où Scrydon échange l'ID-JAG contre un jeton d'accès. |
| Scopes | Scopes facultatifs à demander pour le jeton émis. |
Prérequis (une seule fois, par l'administrateur de votre IdP) :
- Votre organisation est connectée à Scrydon via le SSO d'entreprise (Org Settings → SSO).
- Votre IdP doit prendre en charge les octrois par assertion d'identité (Okta au lancement). L'administrateur de votre IdP enregistre Scrydon comme application autorisée à demander des assertions pour ce serveur MCP et lui attribue les utilisateurs/groupes autorisés à y accéder.
Remarque sur la portée. L'authentification gérée par l'entreprise s'applique aux exécutions initiées par un utilisateur (pour lesquelles Scrydon détient l'identité IdP de l'appelant). Les exécutions entièrement automatisées / en arrière-plan n'ont aucune identité utilisateur à déléguer ; utilisez un mode de repli pour ces serveurs.
OAuth — identifiants client
Renseignez les champs OAuth dans le formulaire du serveur :
| Champ | Description |
|---|---|
| Token URL | Le point de terminaison de jeton OAuth, par ex. https://auth.example.com/oauth/token. |
| Client ID | L'identifiant de client OAuth émis par le serveur d'autorisation du serveur. |
| Client Secret (workspace secret name) | Le nom d'un secret d'espace de travail qui contient le secret client. Scrydon stocke la référence, jamais la valeur du secret, dans la définition du serveur. |
| Scopes | Scopes à demander, séparés par des espaces ou des virgules (facultatif). |
| Resource | Indicateur de ressource RFC 8707 (facultatif). |
| Audience | Audience du jeton (facultatif). |
| Client authentication | Indique s'il faut envoyer le secret client dans le corps de la requête (client_secret_post, la valeur par défaut) ou en HTTP Basic (client_secret_basic). |
Scrydon obtient un jeton à la première utilisation, le met en cache pendant toute sa durée de vie et en obtient automatiquement un nouveau une minute avant son expiration. Utilisez Test Connection pour valider la configuration avant d'enregistrer — un secret manquant ou une demande de jeton rejetée est signalé comme une erreur.
Stocker le secret client
- Ajoutez le secret client comme secret d'espace de travail (Org Settings → Secrets) — par ex.
MCP_CLIENT_SECRET. - Indiquez le nom de ce secret dans le champ Client Secret (workspace secret name).
La valeur du secret ne quitte jamais le magasin de secrets et n'est jamais écrite dans l'enregistrement du serveur MCP.
OAuth — utilisateur (délégué)
L'OAuth délégué exécute la connexion en tant qu'utilisateur connecté, via le flux authorization-code d'OAuth 2.1. Configurez l'Authorization URL et la Token URL (ainsi que l'identifiant client, la référence du secret et les scopes), puis cliquez sur Connect pour connecter le serveur — Scrydon vous redirige vers le fournisseur pour vous connecter, stocke votre jeton et le renouvelle automatiquement. Tant que l'étape de connexion n'est pas terminée, les outils qui ont besoin du serveur signalent qu'une connexion est requise.
Le secret client est résolu par référence depuis le magasin de secrets de l'organisation — ajoutez-le comme secret d'organisation (Org Settings → Secrets) et indiquez son nom dans le champ Client Secret (workspace secret name), comme pour client-credentials.
L'accès délégué est strictement par utilisateur :
- Les appels d'outils s'exécutent avec le propre jeton de l'utilisateur appelant — la connexion d'un utilisateur n'est jamais utilisée pour un autre utilisateur.
- Les exécutions en arrière-plan / déclenchées n'ont aucune identité utilisateur sous laquelle agir : elles échouent donc avec une erreur explicite ; utilisez client-credentials pour les serveurs qui doivent fonctionner sans surveillance.
- Si le fournisseur en amont révoque l'accès (échec du renouvellement du jeton), la connexion est marquée comme nécessitant une nouvelle autorisation et les appels d'outils demandent à l'utilisateur de reconnecter le serveur depuis les paramètres MCP.
Clé API / jeton Bearer
De nombreux serveurs MCP s'authentifient avec une clé API unique de longue durée envoyée dans un en-tête — par exemple Twenty attend Authorization: Bearer <YOUR_API_KEY>. Choisissez API key / Bearer token dans le formulaire du serveur et renseignez :
| Champ | Signification |
|---|---|
| Token secret (workspace secret name) | Le nom d'un secret d'espace de travail contenant le jeton / la clé API. Ajoutez la valeur sous Org Settings → Secrets ; seul le nom est stocké dans l'enregistrement du serveur — la valeur est résolue au moment de la connexion et n'est jamais conservée dans l'entrée du registre. |
| Header name (facultatif) | L'en-tête dans lequel le jeton est envoyé. Vaut Authorization par défaut. |
| Scheme prefix (facultatif) | Le préfixe placé avant le jeton. Vaut Bearer par défaut (envoyé sous la forme Bearer <token>). Définissez un autre schéma, ou laissez-le vide pour envoyer une valeur brute (par ex. X-API-Key: <token>). |
Au moment de la connexion, Scrydon résout le secret nommé et envoie <header>: <scheme> <token>. Si le secret est manquant, l'en-tête est omis et le serveur répond 401, ce qui est remonté comme une erreur de connexion. Aucun échange OAuth n'a lieu.
Les auteurs de packs peuvent livrer un serveur préconfiguré pour ce mode en déclarant auth: { kind: "bearer", tokenRef: "..." } dans le manifeste du serveur MCP — le jeton est une référence de secret, jamais intégrée au bundle.
Remarques
- Les modes OAuth s'appliquent aux serveurs Streamable HTTP. Les serveurs STDIO continuent d'utiliser des identifiants transmis par variables d'environnement.
- Les serveurs existants sans authentification configurée continuent de fonctionner exactement comme avant (mode en-tête statique).