Drittanbieter-AI-Agenten Zugriff auf deinen MCP-Server ermöglichen

tipp:

Entdecke Logtos KI-Lösungen: Authentifizierung (Authentication) und Autorisierung (Authorization) für MCP-Server, KI-Agenten und Apps.

Diese Anleitung führt dich durch die Integration von Logto mit deinem MCP-Server unter Verwendung von mcp-auth und dem offiziellen MCP SDK v2, sodass Drittanbieter-AI-Agenten Benutzer mit deren Zustimmung authentifizieren und sicher auf deinen MCP-Server zugreifen können.

Du lernst, wie du:

• Logto als Autorisierungsserver für deinen MCP-Server konfigurierst.
• Drittanbieter-AI-Agenten einbindest, entweder durch Registrierung von Drittanbieter-Apps oder durch Aktivierung von dynamischen Apps, sodass sich jeder Agent ohne vorherige Registrierung verbinden kann.
• Ein „whoami“-Tool in deinem MCP-Server einrichtest, das die Identitätsansprüche des aktuellen Benutzers zurückgibt.
• Den Ablauf mit einem Drittanbieter-AI-Agenten (MCP-Client) testest.

Nach diesem Tutorial wird dein MCP-Server:

• Benutzer in deinem Logto-Mandanten authentifizieren, mit Zustimmung der Benutzer für Drittanbieter-AI-Agenten.
• JWT Zugangstokens, die von Logto ausgestellt wurden, verifizieren (Signatur, Aussteller, Zielgruppe und Ablauf).
• Die verifizierten Identitätsansprüche (sub, iss, aud, usw.) für den Aufruf des „whoami“-Tools zurückgeben.

Beispielcode:

Den vollständigen, lauffähigen Beispielcode für diese Anleitung findest du im mcp-auth/js Repository:

• whoami-express: Der "whoami"-Server in dieser Anleitung, auf Node.js mit Express.
• whoami: Derselbe Server, gebaut mit fetch-native (web-standard Request / Response mit Hono), bereitstellbar auf Cloudflare Workers.

Unterschied zwischen Drittanbieter-AI-Agent (MCP-Client) und deinem eigenen MCP-Client

Schauen wir uns ein Beispiel an. Stell dir vor, du bist Entwickler und betreibst einen MCP-Server, um E-Mail-Zugriff und Automatisierung zu verwalten.

Offizielle E-Mail-App (Dein eigener MCP-Client)

• Du stellst eine offizielle E-Mail-App bereit, mit der Benutzer ihre E-Mails lesen und verwalten können.
• So funktioniert es: Die offizielle E-Mail-App verbindet sich mit deinem MCP-Server und verwendet Logto zur Authentifizierung der Benutzer. Wenn sich Alice anmeldet, erhält sie automatisch Zugriff auf ihre E-Mails, ohne dass zusätzliche Zustimmungsbildschirme erforderlich sind, da es sich um deine vertrauenswürdige App handelt.

Drittanbieter-AI-Agent (Drittanbieter-MCP-Client)

• Du baust ein Ökosystem rund um deinen MCP-Server auf, sodass ein anderer Entwickler „SmartMail AI“ (einen AI-Assistenten, der E-Mails zusammenfassen und automatisch Meetings planen kann) als Drittanbieter-Client integriert.
• So funktioniert es: SmartMail AI (Drittanbieter-MCP-Client) möchte auf Benutzere-Mails über deinen MCP-Server zugreifen. Wenn sich Alice mit ihrem Konto bei SmartMail AI anmeldet:
  • Ihr wird ein Zustimmungsbildschirm angezeigt, der um Erlaubnis bittet, damit SmartMail AI ihre E-Mails und ihren Kalender lesen darf.
  • Alice kann diesen Zugriff erlauben oder verweigern.
  • Nur die Daten, denen sie zustimmt, werden mit SmartMail AI geteilt, und SmartMail AI kann ohne ausdrückliche erneute Zustimmung auf keine weiteren Daten zugreifen.

Diese Zugriffskontrolle (Berechtigung) stellt die Sicherheit der Benutzerdaten sicher: Auch wenn dein MCP-Server alle Daten verwaltet, können Drittanbieter-Apps wie SmartMail AI nur auf das zugreifen, was der Benutzer ausdrücklich erlaubt hat. Sie können diesen Prozess nicht umgehen, da er durch deine Zugriffskontroll-Implementierung im MCP-Server erzwungen wird.

Zusammenfassung

Client-Typ	Beispiel	Zustimmung erforderlich?	Wer steuert es?
Offizielle E-Mail-App	Deine eigene E-Mail-App	Nein	Du (der Entwickler)
Drittanbieter-AI-Agent	SmartMail AI Assistent	Ja	Ein anderer Entwickler

hinweis:

Wenn du deinen MCP-Server mit deinem eigenen AI-Agenten oder deiner eigenen App integrieren möchtest, siehe bitte die Anleitung Authentifizierung für deine MCP-basierten Apps mit Logto aktivieren.

Voraussetzungen

• Ein Logto Cloud (oder selbst gehosteter) Mandant
• Node.js >= 20 Umgebung

Architektur verstehen

• MCP-Server: Der Server, der Tools und Ressourcen für MCP-Clients bereitstellt. Nach der neuesten MCP-Spezifikation agiert er als OAuth 2.0-Ressourcenserver, der Zugangstokens (Access tokens) validiert, die von Logto ausgestellt wurden.
• MCP-Client: Ein Client, der verwendet wird, um den Authentifizierungsablauf zu starten und die Integration zu testen. Der Drittanbieter-AI-Agent wird in dieser Anleitung als Client verwendet.
• Logto: Dient als OpenID Connect-Provider (Autorisierungsserver), verwaltet Benutzeridentitäten und stellt zielgruppenbezogene JWT-Zugangstokens (Access tokens) für deinen MCP-Server aus.

Ein nicht-normativer Sequenzdiagramm veranschaulicht den Gesamtablauf des Prozesses:

hinweis:

Da sich MCP schnell weiterentwickelt, ist das obige Diagramm möglicherweise nicht vollständig aktuell. Bitte schaue in die mcp-auth-Dokumentation für die neuesten Informationen.

Drittanbieter-AI-Agent in Logto konfigurieren

Um dem Drittanbieter-AI-Agent den Zugriff auf MCP server zu ermöglichen, musst du eine Drittanbieter-App in Logto einrichten. Diese App wird verwendet, um den AI-Agent zu repräsentieren und die notwendigen Zugangsdaten für Authentifizierung (Authentifizierung) und Autorisierung (Autorisierung) zu erhalten.

Was ist eine Drittanbieter-App?:

Eine Drittanbieter-App ist eine Anwendung, die von externen Entwicklern (nicht dem Ressourceneigentümer) erstellt wurde und die Zustimmung des Benutzers benötigt, um auf geschützte Ressourcen zuzugreifen. Im Gegensatz zu First-Party-Apps (deinen eigenen Anwendungen) zeigen Drittanbieter-Apps einen Zustimmungsbildschirm (Consent screen) an, auf dem Benutzer bestimmte Berechtigungen genehmigen müssen, bevor auf ihre Daten zugegriffen werden kann. Dies stellt sicher, dass Benutzer die Kontrolle darüber haben, welche Daten sie mit externen Diensten teilen.

Weitere Informationen findest du unter Drittanbieter-Anwendungen.

Es gibt drei Möglichkeiten, AI-Agents einzubinden:

• App manuell in der Console erstellen, für Tests oder einige bekannte Agents.
• Einen Registrierungsdienst auf der Management API aufbauen, wenn du kontrollieren möchtest, wer Zugangsdaten erhält.
• Dynamische App aktivieren, wenn sich beliebige Agents verbinden dürfen und du keinen Registrierungsschritt möchtest.

Entwicklern erlauben, Drittanbieter-Apps in Logto zu erstellen

Wenn du einen Marktplatz aufbaust oder Entwicklern erlauben möchtest, Drittanbieter-Apps in Logto zu erstellen, kannst du die Logto Management API nutzen, um Drittanbieter-Apps programmatisch zu erstellen. So können Entwickler ihre Anwendungen registrieren und die notwendigen Zugangsdaten für die Authentifizierung (Authentifizierung) erhalten.

Du musst einen eigenen Dienst hosten, um den Client-Registrierungsprozess zu verwalten. Dieser Dienst interagiert mit der Logto Management API, um Drittanbieter-Apps im Namen der Entwickler zu erstellen.

Alternativ kannst du Drittanbieter-Apps auch manuell in der Logto Console erstellen, um dich mit dem Prozess vertraut zu machen.

Beliebigen AI-Agent ohne Vorabregistrierung verbinden lassen

In einem offenen MCP-Ökosystem kennst du die Agents in der Regel nicht im Voraus. Dynamische App entfernt den Registrierungsschritt: Der Agent verwendet eine öffentliche HTTPS-URL, die sein eigenes Client-Metadaten-Dokument bereitstellt, als client_id, und Logto löst diese auf, wenn die Autorisierungsanfrage eintrifft.

Du kontrollierst weiterhin, welche Agents was anfordern dürfen, über die Berechtigungen, die der dynamischen App gewährt werden, und jede Autorisierung läuft über den Zustimmungsbildschirm (Consent screen) des Benutzers.

Drittanbieter-App manuell in Logto erstellen

Du kannst eine Drittanbieter-App manuell in der Logto Console für Testzwecke oder Ad-hoc-Integrationen erstellen. Das ist nützlich, wenn du die Integration schnell testen möchtest, ohne einen vollständigen Client-Registrierungs-Flow zu implementieren.

1. Melde dich in deiner Logto Console an.

2. Gehe zu Anwendungen → Anwendung erstellen → Drittanbieter-App -> OIDC.

3. Gib den App-Namen und andere erforderliche Felder ein und klicke dann auf Anwendung erstellen.

4. Klicke auf den Tab Berechtigungen, um der App Berechtigungen zu gewähren:

   • Benutzer-Abschnitt: Benutzer-Datenberechtigungen wie profile und email, für grundlegende Identitätsansprüche (Claims).
   • API-Ressourcen-Abschnitt: Berechtigungen (Berechtigungen) der API-Ressourcen, die du in Logto definiert hast, z. B. die API-Ressource, die dein MCP server repräsentiert.
   • Organisation-Abschnitt: Organisationsberechtigungen, falls du Logto-Organisationen verwendest.

5. Konfiguriere in der Drittanbieter-App die Scopes, um die von dir gewährten Berechtigungen anzufordern, z. B. openid profile email plus die API-Ressourcen-Berechtigungen.

   Hinweis: openid ist für OIDC erforderlich. Um ein Zugangstoken (Access token) zu erhalten, das an eine API-Ressource gebunden ist, muss die App außerdem den Parameter resource in der Autorisierungsanfrage angeben. MCP-Clients, die der neuesten MCP-Spezifikation folgen, machen dies automatisch basierend auf den Metadaten der geschützten Ressource.

6. Konfiguriere die Redirect-URI deiner Drittanbieter-Anwendung entsprechend. Denke daran, die Redirect-URI auch in Logto zu aktualisieren.

---

Unter der Haube ist eine Drittanbieter-App ein standardmäßiger OAuth 2.0 / OIDC-Client. Das bedeutet, dass du (oder der Drittanbieter-Entwickler) jede OAuth 2.0 / OIDC-Bibliothek oder jedes Framework verwenden kannst, um die Integration mit Logto durchzuführen.

Einige Dinge, die du beachten solltest:

1. Beim Erstellen einer Drittanbieter-App wähle den passenden Anwendungstyp basierend auf der Architektur der App:
   • Traditionelles Web: Verwendet ein Client-Geheimnis zur Authentifizierung.
   • Single Page App / Native: Verwendet PKCE für eine sichere Autorisierung ohne Client-Geheimnis.
2. Die meisten unserer Schnellstart-Anleitungen sind für First-Party-Apps geschrieben, du kannst sie jedoch trotzdem als Referenz für die Integration von Drittanbieter-Apps verwenden.
3. Der Hauptunterschied besteht darin, dass Drittanbieter-Apps einen Zustimmungsbildschirm (Consent screen) anzeigen, der die Benutzer um ausdrückliche Erlaubnis zum Zugriff auf ihre Daten bittet.

Siehe Drittanbieter-Anwendungen für die vollständige Integrationsanleitung.

MCP-Server einrichten

Wir verwenden das offizielle MCP SDK v2 und mcp-auth, um einen MCP-Server mit einem "whoami"-Tool zu erstellen, das die Identitätsansprüche des aktuellen Benutzers zurückgibt.

Projekt erstellen und Abhängigkeiten installieren

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 ist das Kern-MCP SDK v2, das web-standardisierte Request / Response spricht.
• @modelcontextprotocol/express und @modelcontextprotocol/node passen es an Express auf Node.js an.
• mcp-auth liefert den Token-Verifizierer und die OAuth-Discovery-Metadaten für das MCP SDK.

hinweis:

Das MCP SDK v2 und mcp-auth sind ausschließlich ESM und erfordern Node.js >= 20.

Den MCP-Server als API-Ressource registrieren

Die aktuelle MCP-Spezifikation verlangt, dass Zugangstokens (Access tokens) an die Ressource gebunden sind, für die sie ausgestellt wurden (RFC 8707), und mcp-auth erzwingt dies: Der aud-Anspruch (Claim) des Tokens muss mit dem Ressourcenindikator deines MCP-Servers übereinstimmen. In Logto geschieht dies, indem du eine API-Ressource erstellst, deren Indikator mit der URL deines MCP-Servers übereinstimmt:

1. Melde dich bei deiner Logto-Konsole an.
2. Gehe zu API-Ressourcen → API-Ressource erstellen.
3. Fülle die Details aus und klicke dann auf API-Ressource erstellen:
   • API-Name: Gib einen Namen ein, z. B. "Who am I".
   • API-Indikator: Gib http://localhost:3001/ ein. Er muss mit dem Ressourcenindikator übereinstimmen, den wir im MCP-Server konfigurieren.

Abschließender Schrägstrich im Ressourcenindikator:

Füge immer einen abschließenden Schrägstrich (/) im Ressourcenindikator hinzu. Aufgrund eines aktuellen Fehlers im offiziellen MCP SDK fügen Clients, die das SDK verwenden, beim Starten von Authentifizierungsanfragen automatisch einen abschließenden Schrägstrich zu Ressourcenindikatoren hinzu. Wenn dein Ressourcenindikator keinen abschließenden Schrägstrich enthält, schlägt die Ressourcenvalidierung für diese Clients fehl.

MCP Auth mit Logto konfigurieren

Deklariere deinen MCP-Server als geschützte Ressource: seinen Ressourcenindikator und den Autorisierungsserver, dem er vertraut. Ersetze <your-logto-issuer-endpoint> durch den zuvor kopierten Aussteller-Endpunkt (zu finden auf der Anwendungsdetailseite unter Endpoints & Credentials, z. B. https://my-project.logto.app/oidc).

In whoami.js:

import { MCPAuth } from 'mcp-auth';

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

const mcpAuth = new MCPAuth({
  protectedResourceMetadata: {
    // Der Ressourcenindikator; muss mit dem in Logto registrierten API-Ressourcenindikator übereinstimmen
    resource: 'http://localhost:3001/',
    // Der von diesem MCP-Server vertraute Autorisierungsserver
    authorizationServer: { issuer: authIssuer, type: 'oidc' },
  },
});

Die Metadaten des Autorisierungsservers werden bei Bedarf lazy geladen und anschließend zwischengespeichert. Die MCPAuth-Instanz überprüft JWT-Zugangstokens (Access tokens) anhand von Logtos JWKS — Signatur, Aussteller (Issuer), Zielgruppe (Audience) und Ablauf werden alle durchgesetzt. Eine handgeschriebene Token-Überprüfung ist nicht erforderlich.

Das "whoami"-Tool implementieren

Nun implementieren wir das "whoami"-Tool, das die Identitätsansprüche des aktuellen Benutzers aus dem verifizierten Zugangstoken zurückgibt. Verwende getAuthInfo, um die von mcp-auth verifizierten Authentifizierungsinformationen aus dem Callback-Kontext des Tools auszulesen.

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

// Fabrikfunktion zum Erstellen einer MCP-Serverinstanz
// Jede Anfrage erhält ihre eigene Serverinstanz, um Anfragen zu isolieren
const createMcpServer = () => {
  const mcpServer = new McpServer({
    name: 'WhoAmI',
    version: '0.0.0',
  });

  // Füge dem Server ein Tool hinzu, das die Informationen des aktuellen Benutzers zurückgibt
  mcpServer.registerTool(
    'whoami',
    {
      description: 'Hole die Informationen des aktuellen Benutzers',
    },
    (context) => {
      const { claims } = getAuthInfo(context);
      return {
        content: [{ type: 'text', text: JSON.stringify(claims) }],
      };
    }
  );

  return mcpServer;
};

Den Server verbinden

Zum Schluss stelle die OAuth-Discovery-Dokumente (RFC 9728 / RFC 8414) bereit, damit MCP-Clients deinen Autorisierungsserver finden können, und schütze den MCP-Endpunkt mit der Bearer-Auth-Middleware des SDKs.

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

const PORT = 3001;

// Der MCP-Handler spricht web-standardisiertes Request / Response; `toNodeHandler` passt ihn an Express an
const mcpNodeHandler = toNodeHandler(createMcpHandler(createMcpServer));

const app = createMcpExpressApp();

// Stelle die OAuth-Discovery-Dokumente (`/.well-known/...`) bereit, standardmäßig öffentlich
app.use(mcpAuthMetadataRouter(await mcpAuth.getAuthMetadataOptions()));

app.all(
  '/',
  // Erfordert ein gültiges Bearer-Token; die verifizierten Authentifizierungsinformationen werden über `req.auth` an den Handler weitergegeben
  requireBearerAuth(mcpAuth.getBearerAuthOptions()),
  // `createMcpExpressApp` verwendet `express.json()`, wodurch der Request-Stream geleert wird, daher wird der
  // geparste Body explizit weitergegeben
  async (request, response) => mcpNodeHandler(request, response, request.body)
);

app.listen(PORT);

Starte den Server mit:

npm start

Integration testen

1. Starte den MCP-Server.
2. Verbinde den Drittanbieter-AI-Agenten mit deinem MCP-Server und rufe das whoami-Tool auf.
3. Der Agent erhält eine 401 Unauthorized-Antwort, entdeckt Logto über die geschützten Ressourcen-Metadaten des MCP-Servers und leitet den Benutzer zur Authentifizierung an Logto weiter.
4. Der Benutzer meldet sich an und sieht den Zustimmungsbildschirm, auf dem die vom Agenten angeforderten Berechtigungen aufgelistet sind, und genehmigt (oder verweigert) den Zugriff.
5. Der Agent erhält ein zielgruppenbasiertes JWT Zugangstoken und verwendet es, um das Tool erneut aufzurufen.
6. Der MCP-Server verifiziert das Zugangstoken anhand von Logtos JWKS und gibt die verifizierten Identitätsansprüche an den Agenten zurück.

Weiterführende Informationen

Dein MCP-Server verifiziert jetzt eingehende Zugangstokens von Drittanbieter-AI-Agenten. Als nächsten Schritt erfahre, wie er im Namen von Benutzern sicher deine nachgelagerten Business-APIs aufrufen kann, ohne Token-Durchleitung oder Verlust des Benutzerkontexts:

Wie ein MCP-Server deine API im Namen von Benutzern aufruft: eine produktionsreife Token-Strategie