Authentification & Autorisation

Un système MCP-first nécessite une architecture de sécurité précise. Tous les clients ne peuvent pas voir tous les outils. Tous les agents ne peuvent pas appeler tous les outils. Toutes les actions ne peuvent pas être exécutées de manière autonome. Toutes les informations ne peuvent pas accéder au contexte IA.

Pour cela, il est nécessaire de bien distinguer les différents types d’identités et de définir pour chacun le mécanisme d’authentification approprié.

Les cinq identités

Utilisateur humain

Un vrai utilisateur du système, avec une identité personnelle et des droits liés aux rôles. Types typiques : administrateur, employé, client, chef de projet, agent de support, directeur général.

L’utilisateur humain est l’identité de base. Tous les contextes délégués se réfèrent en définitive à lui.

Client MCP

L’application connectée au serveur MCP. Le client MCP n’est pas un utilisateur, mais un acteur technique avec son propre niveau de confiance.

Exemples : Claude Desktop, application IA interne, propre application mobile, propre agent worker, client d’intégration externe.

Le client ne voit que les outils correspondant à son niveau de confiance et aux scopes configurés.

Identité d’agent

L’agent ou le workflow concret qui agit. Un agent n’est pas identique au client qui l’exécute, il a sa propre identité décrite avec des capacités limitées.

Exemples : assistant commercial, assistant de paie, agent de support, agent DevOps, agent de reporting, assistant personnel.

Contexte utilisateur délégué

Le contexte utilisateur délégué garantit qu’un agent a exactement les droits, et seulement ceux-là, que l’utilisateur au nom duquel il agit. Le directeur général peut voir les données salariales, un agent assistant commercial ne peut pas pour autant obtenir ces données dans son contexte.

Identité de service

Pour les processus backend-to-backend sans contexte utilisateur direct. Les identités de service sont des acteurs techniques avec des scopes étroitement définis et fixes.

Exemples : worker d’import, job planifié, worker de synchronisation, agent de monitoring, worker de facturation.

Authentification pour les humains

Les utilisateurs humains s’authentifient via des procédures établies. Le choix de la procédure dépend des exigences de sécurité et du contexte :

• E-mail + Mot de passe, Accès de base, toujours combiné avec 2FA
• Passkeys, Alternative anti-hameçonnage aux mots de passe, à privilégier
• TOTP / 2FA, Second facteur pour tous les domaines sensibles
• SSO, Pour les environnements d’entreprise avec gestion centralisée des identités
• OAuth / OpenID Connect, Pour les connexions tierces et les accès délégués

Authentification pour les clients MCP

Les clients MCP sont authentifiés via OAuth 2.1 avec Authorization Code Flow et PKCE. Cela prévient les attaques par injection de code et convient aux clients publics (sans secret client sécurisé).

Exigences supplémentaires :

• Durées d’accès courtes pour les tokens, minimise le potentiel de dommages en cas de fuite de token
• Rotation des tokens de rafraîchissement, chaque utilisation d’un token de rafraîchissement en crée un nouveau ; l’ancien est immédiatement invalidé
• Liste blanche de clients, pour les systèmes sensibles, seuls les clients explicitement enregistrés sont autorisés ; l’enregistrement dynamique des clients est restreint ou désactivé
• Validation des URI de redirection, seules les URI préalablement enregistrées sont acceptées ; les redirections ouvertes sont un vecteur d’attaque courant
• Liaison de token, là où c’est techniquement possible, le token est lié au client

Authentification pour les services internes

La communication backend-to-backend suit des exigences différentes de l’authentification des utilisateurs ou des clients. Des mécanismes techniques sans étape d’authentification interactive sont utilisés ici :

• mTLS, authentification TLS mutuelle ; les deux parties s’identifient avec des certificats
• Tokens de service signés, tokens à courte durée de vie, signés cryptographiquement, avec des scopes étroitement définis ; pas de secrets partagés à longue durée de vie
• Gestionnaire de secrets, les identifiants, certificats et clés ne sont jamais stockés dans des fichiers de configuration, mais gérés et tournés via un gestionnaire de secrets centralisé
• Zones réseau privées, les services internes communiquent dans des segments réseau isolés ; pas d’accès direct depuis le réseau public
• Liste blanche IP, pour les systèmes critiques, l’accès est en plus limité aux plages IP connues
• Rotation des tokens, les tokens de service ont également une courte durée de vie et sont régulièrement renouvelés