Autoriser l’accès d’un agent IA tiers à votre serveur MCP

Ce guide vous accompagne dans l’intégration de Logto avec votre serveur MCP en utilisant mcp-auth, vous permettant d’authentifier les utilisateurs et de récupérer en toute sécurité leurs informations d’identité via le flux standard OpenID Connect.

Vous apprendrez à:

• Configurer Logto comme serveur d’autorisation pour votre serveur MCP.
• Mettre en place un outil “whoami” dans votre serveur MCP pour retourner les revendications d’identité de l’utilisateur actuel.
• Tester le flux avec un agent IA tiers (client MCP).

Après ce tutoriel, votre serveur MCP pourra:

• Authentifier les utilisateurs dans votre tenant Logto.
• Retourner les revendications d’identité (sub, username, name, email, etc.) lors de l’appel de l’outil "whoami".

Différence entre un agent IA tiers (client MCP tiers) et votre propre client MCP

Prenons un exemple. Imaginez que vous êtes un développeur exploitant un serveur MCP pour gérer l’accès aux e-mails et l’automatisation.

Application e-mail officielle (Votre propre client MCP)

• Vous fournissez une application e-mail officielle permettant aux utilisateurs de lire et gérer leurs e-mails.
• Fonctionnement: L’application e-mail officielle se connecte à votre serveur MCP en utilisant Logto pour authentifier les utilisateurs. Lorsque Alice se connecte, elle accède automatiquement à ses e-mails, sans écran de permission supplémentaire, car il s’agit de votre application de confiance.

Agent IA tiers (Client MCP tiers)

• Vous développez un écosystème autour de votre serveur MCP, un autre développeur crée donc “SmartMail AI” (un assistant IA capable de résumer les e-mails et de planifier des réunions automatiquement) en l’intégrant comme client tiers.
• Fonctionnement: SmartMail AI (client MCP tiers) souhaite accéder aux e-mails des utilisateurs via votre serveur MCP. Lorsque Alice se connecte à SmartMail AI avec son compte:
  • Un écran de consentement s’affiche, demandant l’autorisation à SmartMail AI de lire ses e-mails et son agenda.
  • Alice peut autoriser ou refuser cet accès.
  • Seules les données auxquelles elle consent sont partagées avec SmartMail AI, et SmartMail AI ne peut accéder à aucune donnée supplémentaire sans un nouveau consentement explicite.

Ce contrôle d’accès (permission) garantit la sécurité des données utilisateur: même si votre serveur MCP gère toutes les données, les applications tierces comme SmartMail AI ne peuvent accéder qu’aux données explicitement autorisées par l’utilisateur. Elles ne peuvent pas contourner ce processus, car il est imposé par votre implémentation du contrôle d’accès dans le serveur MCP.

Résumé

Type de client	Exemple	Consentement requis?	Qui le contrôle?
Application e-mail officielle	Votre propre application e-mail	Non	Vous (le développeur)
Agent IA tiers	Assistant SmartMail AI	Oui	Un autre développeur

remarque:

Si vous souhaitez intégrer votre serveur MCP avec votre propre agent IA ou application, veuillez consulter le guide Activer l’authentification pour vos applications propulsées par MCP avec Logto.

Prérequis

• Un tenant Logto Cloud (ou auto-hébergé)
• Un environnement Node.js ou Python

Comprendre l’architecture

• Serveur MCP : Le serveur qui expose des outils et des ressources aux clients MCP.
• Client MCP : Un client utilisé pour initier le flux d’authentification et tester l’intégration. L’agent IA tiers sera utilisé comme client dans ce guide.
• Logto : Sert de fournisseur OpenID Connect (serveur d’autorisation) et gère les identités des utilisateurs.

Un diagramme de séquence non normatif illustre le déroulement global du processus :

remarque:

En raison de l’évolution rapide de MCP, le diagramme ci-dessus peut ne pas être entièrement à jour. Veuillez consulter la documentation mcp-auth pour les informations les plus récentes.

Configurer un agent IA tiers dans Logto

Pour permettre à l’agent IA tiers d’accéder à serveur MCP, vous devez configurer une application tierce dans Logto. Cette application sera utilisée pour représenter l’agent IA et obtenir les identifiants nécessaires à l’authentification et à l’autorisation.

Autoriser les développeurs à créer des applications tierces dans Logto

Si vous construisez une place de marché ou souhaitez permettre aux développeurs de créer des applications tierces dans Logto, vous pouvez utiliser la Logto Management API pour créer des applications tierces de manière programmatique. Cela permet aux développeurs d’enregistrer leurs applications et d’obtenir les identifiants nécessaires à l’authentification.

Vous devrez héberger votre propre service pour gérer le processus d’enregistrement des clients. Ce service interagira avec la Logto Management API pour créer des applications tierces au nom des développeurs.

Alternativement, vous pouvez créer manuellement des applications tierces dans la Console Logto pour vous familiariser avec le processus.

Créer manuellement une application tierce dans Logto

Vous pouvez créer manuellement une application tierce dans la Console Logto à des fins de test ou pour des intégrations ponctuelles. Ceci est utile lorsque vous souhaitez tester rapidement l’intégration sans mettre en œuvre un flux complet d’enregistrement de client.

1. Connectez-vous à votre Console Logto.

2. Allez dans Applications → Créer une application → Application tierce -> OIDC.

3. Renseignez le nom de l’application et les autres champs requis, puis cliquez sur Créer une application.

4. Cliquez sur l’onglet Permissions, dans la section Utilisateur, cliquez sur "Ajouter".

5. Dans la boîte de dialogue qui s’ouvre -> Données utilisateur -> sélectionnez les permissions profile, email, puis cliquez sur Enregistrer.

6. Dans l’application tierce, configurez les portées (scopes) pour demander les permissions (portées) openid profile email.

   Remarque : openid est requis pour OIDC, et profile et email sont les permissions que vous avez ajoutées à l’étape précédente.

7. Configurez l’URI de redirection de votre application tierce en conséquence. N’oubliez pas de mettre à jour l’URI de redirection dans Logto également.

---

Sous le capot, une application tierce n'est qu'un client OAuth 2.0 / OIDC standard. Cela signifie que vous (ou le développeur tiers) pouvez utiliser n'importe quelle bibliothèque ou framework OAuth 2.0 / OIDC pour intégrer Logto.

Si vous n'êtes pas familier avec OAuth 2.0 ou OIDC, vous pouvez commencer par suivre l'un de nos guides de démarrage rapide “Web traditionnel”.

Quelques points à garder à l'esprit :

1. Logto exige actuellement que les applications tierces soient des applications “Web traditionnel”. En d'autres termes, l'application doit disposer d'un serveur backend (ou backend-for-frontend) pour stocker en toute sécurité le secret client.
2. La plupart de nos guides de démarrage rapide sont rédigés pour des applications propriétaires, mais vous pouvez tout de même les utiliser comme référence pour l'intégration d'applications tierces.
3. La principale différence est que les applications tierces afficheront un écran de consentement (Consent screen), demandant aux utilisateurs une permission explicite pour accéder à leurs données.

Vous pouvez trouver plus d'informations dans nos guides de démarrage rapide.

Configurer le serveur MCP

Créer le projet et installer les dépendances

Python

mkdir mcp-server
cd mcp-server
uv init # Ou utilisez votre propre structure de projet
uv add "mcp[cli]" starlette uvicorn mcpauth # Ou utilisez le gestionnaire de paquets de votre choix

Node.js

mkdir mcp-server
cd mcp-server
npm init -y
npm install @modelcontextprotocol/sdk express mcp-auth # Ou utilisez le gestionnaire de paquets de votre choix

Configurer l’authentification MCP avec Logto

N'oubliez pas de remplacer <your-logto-issuer-endpoint> par l’endpoint de l’émetteur que vous avez copié précédemment.

Python

Dans whoami.py :

from mcpauth import MCPAuth
from mcpauth.config import AuthServerType
from mcpauth.utils import fetch_server_config

auth_issuer = '<your-logto-issuer-endpoint>'
auth_server_config = fetch_server_config(auth_issuer, type=AuthServerType.OIDC)
mcp_auth = MCPAuth(server=auth_server_config)

Node.js

Dans whoami.js :

import { MCPAuth, fetchServerConfig } from 'mcp-auth';

const authIssuer = '<your-logto-issuer-endpoint>';
const mcpAuth = new MCPAuth({
  server: await fetchServerConfig(authIssuer, { type: 'oidc' }),
});

Implémenter la vérification du jeton

Puisque nous allons vérifier le jeton d’accès (Access token) et récupérer les informations utilisateur, nous devons implémenter la vérification du jeton d’accès comme suit :

Python

import requests
from mcpauth.types import AuthInfo

def verify_access_token(token: str) -> AuthInfo:
    endpoint = auth_server_config.metadata.userinfo_endpoint
    response = requests.get(
        endpoint,
        headers={"Authorization": f"Bearer {token}"},
    )
    response.raise_for_status()
    data = response.json()
    return AuthInfo(
        token=token,
        subject=data.get("sub"),
        issuer=auth_server_config.metadata.issuer,
        claims=data,
    )

Node.js

const verifyToken = async (token) => {
  const { userinfoEndpoint, issuer } = mcpAuth.config.server.metadata;
  const response = await fetch(userinfoEndpoint, {
    headers: { Authorization: `Bearer ${token}` },
  });
  if (!response.ok) throw new Error('Token verification failed');
  const userInfo = await response.json();
  return {
    token,
    issuer,
    subject: userInfo.sub,
    claims: userInfo,
  };
};

Implémenter l’outil "whoami"

Implémentons maintenant l’outil "whoami" qui retourne les revendications d’identité de l’utilisateur courant en interrogeant l’endpoint userinfo avec le jeton d’accès envoyé par le client.

remarque:

Nous utilisons le transport SSE pour l’exemple en raison de l’absence de prise en charge officielle du transport HTTP Streamable dans la version actuelle du SDK. Théoriquement, vous pouvez utiliser n’importe quel transport compatible HTTP.

Python

from mcp.server.fastmcp import FastMCP
from starlette.applications import Starlette
from starlette.routing import Mount
from starlette.middleware import Middleware

mcp = FastMCP("WhoAmI")

@mcp.tool()
def whoami() -> dict:
    """
    Retourne les informations d'identité de l'utilisateur courant.
    """
    return (
        mcp_auth.auth_info.claims
        if mcp_auth.auth_info
        else {"error": "Not authenticated"}
    )

bearer_auth = Middleware(mcp_auth.bearer_auth_middleware(verify_access_token))
app = Starlette(
    routes=[
        mcp_auth.metadata_route(),  # Sert les métadonnées OIDC pour la découverte
        Mount('/', app=mcp.sse_app(), middleware=[bearer_auth]),
    ],
)

Lancez le serveur avec :

uvicorn whoami:app --host 0.0.0.0 --port 3001

Node.js

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import express from 'express';

// Créer le serveur MCP et enregistrer l’outil whoami
const server = new McpServer({ name: 'WhoAmI', version: '0.0.0' });
server.tool('whoami', ({ authInfo }) => ({
  content: [
    { type: 'text', text: JSON.stringify(authInfo?.claims ?? { error: 'Not authenticated' }) },
  ],
}));

// Application Express & middleware MCP Auth
const app = express();
app.use(mcpAuth.delegatedRouter());
app.use(mcpAuth.bearerAuth(verifyToken));

// Transport SSE (comme dans la documentation du SDK)
const transports = {};
app.get('/sse', async (_req, res) => {
  const transport = new SSEServerTransport('/messages', res);
  transports[transport.sessionId] = transport;
  res.on('close', () => delete transports[transport.sessionId]);
  await server.connect(transport);
});
app.post('/messages', async (req, res) => {
  const sessionId = String(req.query.sessionId);
  const transport = transports[sessionId];
  if (transport) await transport.handlePostMessage(req, res, req.body);
  else res.status(400).send('No transport found for sessionId');
});

app.listen(3001);

Lancez le serveur avec :

node whoami.js

Tester l’intégration

1. Démarrez le serveur MCP.
2. Démarrez l’agent IA.
3. Dans le client, invoquez l’outil whoami pour récupérer les revendications d’identité de l’utilisateur actuel.
4. Le client doit gérer la réponse 401 Non autorisé et rediriger l’utilisateur vers Logto pour l’authentification.
5. Après une authentification réussie, le client doit recevoir un jeton d’accès et l’utiliser pour effectuer des requêtes vers le serveur MCP.
6. Le client doit pouvoir récupérer les revendications d’identité depuis le serveur MCP à l’aide du jeton d’accès.

Python

Le code complet du serveur MCP est disponible dans le dépôt mcp-auth/python.

Node.js

Le code complet du serveur MCP est disponible dans le dépôt mcp-auth/js.