Autoriser l’accès des agents IA tiers à votre serveur MCP

astuce:

Découvrez les solutions IA de Logto : authentification (Authentication) et autorisation (Authorization) pour les serveurs MCP, les agents IA et les applications.

Ce guide vous accompagne dans l’intégration de Logto avec votre serveur MCP en utilisant mcp-auth et le SDK officiel MCP v2, permettant aux agents IA tiers d’authentifier les utilisateurs avec leur consentement et d’accéder en toute sécurité à votre serveur MCP.

Vous apprendrez à :

Configurer Logto comme serveur d’autorisation pour votre serveur MCP.
Intégrer des agents IA tiers, soit en enregistrant des applications tierces, soit en activant application dynamique afin que tout agent puisse se connecter sans pré-enregistrement.
Mettre en place un outil “whoami” dans votre serveur MCP pour retourner les revendications d’identité de l’utilisateur courant.
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, avec le consentement de l’utilisateur pour les agents IA tiers.
Vérifier les jetons d’accès JWT émis par Logto (signature, émetteur, audience et expiration).
Retourner les revendications d’identité vérifiées (sub, iss, aud, etc.) lors de l’appel de l’outil "whoami".

Exemple de code:

Le code exemple complet et exécutable pour ce guide est disponible dans le dépôt mcp-auth/js :

whoami-express : le serveur "whoami" de ce guide, sur Node.js avec Express.
whoami : le même serveur construit avec fetch-native (web-standard Request / Response avec Hono), déployable sur Cloudflare Workers.

Différence entre agent IA tiers (client MCP) 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 consentement 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, et un autre développeur crée “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’à ce que l’utilisateur a explicitement autorisé. 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 alimentées par MCP avec Logto.

Prérequis

Un tenant Logto Cloud (ou auto-hébergé)
Environnement Node.js >= 20

Comprendre l’architecture

Serveur MCP : Le serveur qui expose des outils et des ressources aux clients MCP. Conformément à la dernière spécification MCP, il agit en tant que serveur de ressources OAuth 2.0 qui valide les jetons d’accès émis par Logto.
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), gère les identités des utilisateurs et émet des jetons d’accès JWT liés à l’audience pour votre serveur MCP.

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 dernières informations.

Configurer un agent IA tiers dans Logto

Pour permettre à l'agent IA tiers d'accéder à votre 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.

Qu'est-ce qu'une application tierce ?:

Une application tierce est une application créée par des développeurs externes (non propriétaire de la ressource) qui nécessite le consentement de l'utilisateur pour accéder à des ressources protégées. Contrairement aux applications propriétaires (vos propres applications), les applications tierces affichent un écran de consentement demandant aux utilisateurs d'approuver des permissions spécifiques avant d'accéder à leurs données. Cela garantit que les utilisateurs gardent le contrôle sur les données qu'ils partagent avec des services externes.

Pour en savoir plus, consultez Applications tierces.

Il existe trois façons d'intégrer des agents IA :

Créer manuellement l'application dans la Console, pour des tests ou quelques agents connus.
Construire un service d'enregistrement sur le Management API, si vous souhaitez contrôler qui obtient des identifiants.
Activer l'application dynamique, si n'importe quel agent peut se connecter et que vous ne souhaitez pas d'étape d'enregistrement.

Permettre aux développeurs de 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 le 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 le 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.

Permettre à n'importe quel agent IA de se connecter sans pré-enregistrement

Dans un écosystème MCP ouvert, vous ne connaissez généralement pas les agents à l'avance. Application dynamique supprime l'étape d'enregistrement : l'agent utilise une URL HTTPS publique servant son propre document de métadonnées client comme client_id, et Logto le résout lorsque la requête d'autorisation arrive.

Vous gardez toujours le contrôle sur ce que les agents peuvent demander via les permissions accordées à l'application dynamique, et chaque autorisation passe par l'écran de consentement utilisateur.

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.

Connectez-vous à votre Console Logto.
Allez dans Applications → Créer une application → Application tierce -> OIDC.
Renseignez le nom de l'application et les autres champs requis, puis cliquez sur Créer l'application.
Cliquez sur l'onglet Permissions pour accorder des permissions à l'application :
- Section Utilisateur : permissions sur les données utilisateur telles que profile et email, pour les revendications d'identité de base.
- Section Ressource API : permissions (portées) des ressources API que vous avez définies dans Logto, par exemple la ressource API qui représente votre serveur MCP.
- Section Organisation : permissions d'organisation, si vous utilisez les organisations Logto.
Dans l'application tierce, configurez les portées pour demander les permissions que vous avez accordées, par exemple, openid profile email plus les portées des ressources API.

Remarque : openid est requis pour OIDC. Pour recevoir un jeton d’accès lié à une ressource API, l'application doit également inclure le paramètre resource dans la requête d'autorisation. Les clients MCP qui suivent la dernière spécification MCP le font automatiquement en fonction des métadonnées de la ressource protégée.
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 est 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.

Quelques points à garder à l'esprit :

Lors de la création d'une application tierce, sélectionnez le type d'application approprié en fonction de l'architecture de l'application :
- Web traditionnel : Utilise un secret client pour l'authentification.
- Application monopage / Native : Utilise PKCE pour une autorisation sécurisée sans secret client.
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'une application tierce.
La principale différence est que les applications tierces afficheront un écran de consentement (Consent screen), demandant aux utilisateurs une autorisation explicite pour accéder à leurs données.

Consultez Applications tierces pour un guide d'intégration complet.

Configurer le serveur MCP

Nous allons utiliser le SDK officiel MCP v2 et mcp-auth pour créer un serveur MCP avec un outil "whoami" qui retourne les revendications d'identité de l'utilisateur actuel.

Créer le projet et installer les dépendances

mkdir mcp-server
cd mcp-server
npm init -y
npm pkg set type="module"
npm pkg set main="whoami.js"
npm pkg set scripts.start="node whoami.js"
npm install @modelcontextprotocol/server @modelcontextprotocol/express @modelcontextprotocol/node express mcp-auth

@modelcontextprotocol/server est le SDK MCP v2 principal, qui utilise les standards web Request / Response.
@modelcontextprotocol/express et @modelcontextprotocol/node l'adaptent à Express sur Node.js.
mcp-auth fournit le vérificateur de jeton et les métadonnées de découverte OAuth pour le SDK MCP.

remarque:

Le SDK MCP v2 et mcp-auth sont uniquement ESM et nécessitent Node.js >= 20.

Enregistrer le serveur MCP comme ressource API

La dernière spécification MCP exige que les jetons d’accès soient liés à la ressource pour laquelle ils sont émis (RFC 8707), et mcp-auth l'applique : la revendication aud du jeton doit correspondre à l'identifiant de ressource de votre serveur MCP. Dans Logto, cela se fait en créant une ressource API dont l'indicateur correspond à l'URL de votre serveur MCP :

Connectez-vous à votre Console Logto.
Allez dans Ressources API → Créer une ressource API.
Remplissez les détails, puis cliquez sur Créer une ressource API :
- Nom de l’API : Saisissez un nom, par exemple "Who am I".
- Identifiant de l’API : Saisissez http://localhost:3001/. Il doit correspondre à l'identifiant de ressource que nous allons configurer dans le serveur MCP.

Barre oblique finale dans l’indicateur de ressource:

Incluez toujours une barre oblique finale (/) dans l’indicateur de ressource. En raison d’un bug actuel dans le SDK officiel MCP, les clients utilisant le SDK ajouteront automatiquement une barre oblique finale aux identifiants de ressource lors de l’initiation des requêtes d’authentification. Si votre indicateur de ressource n’inclut pas la barre oblique, la validation de la ressource échouera pour ces clients.

Configurer MCP Auth avec Logto

Déclarez votre serveur MCP comme une ressource protégée : son identifiant de ressource et le serveur d’autorisation auquel il fait confiance. N’oubliez pas de remplacer <your-logto-issuer-endpoint> par l’endpoint de l’émetteur que vous avez copié précédemment (trouvé dans la page de détails de l’application sous Endpoints & Credentials, par exemple https://my-project.logto.app/oidc).

Dans whoami.js :

import { MCPAuth } from 'mcp-auth';

const authIssuer = '<your-logto-issuer-endpoint>';

const mcpAuth = new MCPAuth({
  protectedResourceMetadata: {
    // L’identifiant de la ressource ; doit correspondre à l’indicateur de ressource API enregistré dans Logto
    resource: 'http://localhost:3001/',
    // Le serveur d’autorisation de confiance pour ce serveur MCP
    authorizationServer: { issuer: authIssuer, type: 'oidc' },
  },
});

Les métadonnées du serveur d’autorisation sont récupérées à la demande lors du premier besoin et mises en cache par la suite. L’instance MCPAuth vérifie les jetons d’accès JWT avec le JWKS de Logto — la signature, l’émetteur, l’audience et l’expiration sont tous appliqués. Aucune vérification manuelle des jetons n’est nécessaire.

Implémenter l’outil "whoami"

Implémentons maintenant l’outil "whoami" qui retourne les revendications d'identité de l'utilisateur actuel à partir du jeton d’accès vérifié. Utilisez getAuthInfo pour lire les informations d’authentification que mcp-auth a vérifiées à partir du contexte du callback de l’outil.

import { McpServer } from '@modelcontextprotocol/server';
import { getAuthInfo } from 'mcp-auth';

// Fonction usine pour créer une instance de serveur MCP
// Chaque requête obtient sa propre instance de serveur, gardant les requêtes isolées
const createMcpServer = () => {
  const mcpServer = new McpServer({
    name: 'WhoAmI',
    version: '0.0.0',
  });

  // Ajoute un outil au serveur qui retourne les informations de l’utilisateur actuel
  mcpServer.registerTool(
    'whoami',
    {
      description: 'Obtenir les informations de l’utilisateur actuel',
    },
    (context) => {
      const { claims } = getAuthInfo(context);
      return {
        content: [{ type: 'text', text: JSON.stringify(claims) }],
      };
    }
  );

  return mcpServer;
};

Connecter le serveur

Enfin, servez les documents de découverte OAuth (RFC 9728 / RFC 8414) pour que les clients MCP puissent trouver votre serveur d’autorisation, et protégez l’endpoint MCP avec le middleware Bearer auth du SDK.

import {
  createMcpExpressApp,
  mcpAuthMetadataRouter,
  requireBearerAuth,
} from '@modelcontextprotocol/express';
import { toNodeHandler } from '@modelcontextprotocol/node';
import { createMcpHandler } from '@modelcontextprotocol/server';

const PORT = 3001;

// Le handler MCP utilise les standards web Request / Response ; `toNodeHandler` l’adapte à Express
const mcpNodeHandler = toNodeHandler(createMcpHandler(createMcpServer));

const app = createMcpExpressApp();

// Sert les documents de découverte OAuth (`/.well-known/...`), publics par conception
app.use(mcpAuthMetadataRouter(await mcpAuth.getAuthMetadataOptions()));

app.all(
  '/',
  // Nécessite un jeton Bearer valide ; les infos d’authentification vérifiées sont transmises au handler via `req.auth`
  requireBearerAuth(mcpAuth.getBearerAuthOptions()),
  // `createMcpExpressApp` applique `express.json()`, qui vide le flux de requête, donc le
  // corps analysé est transmis explicitement
  async (request, response) => mcpNodeHandler(request, response, request.body)
);

app.listen(PORT);

Lancez le serveur avec :

npm start

Tester l’intégration

Démarrez le serveur MCP.
Connectez l’agent IA tiers à votre serveur MCP et invoquez l’outil whoami.
L’agent reçoit une réponse 401 Non autorisé, découvre Logto via les métadonnées de ressource protégée du serveur MCP, puis redirige l’utilisateur vers Logto pour l’authentification.
L’utilisateur se connecte et examine l’écran de consentement, qui liste les permissions demandées par l’agent, puis approuve (ou refuse) l’accès.
L’agent reçoit un jeton d’accès JWT lié à l’audience et l’utilise pour invoquer à nouveau l’outil.
Le serveur MCP vérifie le jeton d’accès via le JWKS de Logto et retourne les revendications d’identité vérifiées à l’agent.

Pour aller plus loin

Votre serveur MCP vérifie désormais les jetons d’accès entrants des agents IA tiers. Pour la suite, découvrez comment il peut appeler en toute sécurité vos API métier en aval au nom des utilisateurs, sans transfert de jeton ni perte de contexte utilisateur :

Comment un serveur MCP appelle votre API au nom des utilisateurs : une stratégie de jeton en production

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

Prérequis​

Comprendre l’architecture​

Configurer un agent IA tiers dans Logto​

Permettre aux développeurs de créer des applications tierces dans Logto​

Permettre à n'importe quel agent IA de se connecter sans pré-enregistrement​

Créer manuellement une application tierce dans Logto​

Configurer le serveur MCP​

Créer le projet et installer les dépendances​

Enregistrer le serveur MCP comme ressource API​

Configurer MCP Auth avec Logto​

Implémenter l’outil "whoami"​

Connecter le serveur​

Tester l’intégration​

Pour aller plus loin​

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

Prérequis

Comprendre l’architecture

Configurer un agent IA tiers dans Logto

Permettre aux développeurs de créer des applications tierces dans Logto

Permettre à n'importe quel agent IA de se connecter sans pré-enregistrement

Créer manuellement une application tierce dans Logto

Configurer le serveur MCP

Créer le projet et installer les dépendances

Enregistrer le serveur MCP comme ressource API

Configurer MCP Auth avec Logto

Implémenter l’outil "whoami"

Connecter le serveur

Tester l’intégration

Pour aller plus loin