Zum Hauptinhalt springen

Tutorial: Baue einen Todo-Manager

Python SDK verfügbar

MCP Auth ist auch für Python verfügbar! Schau dir das Python SDK Repository für Installation und Nutzung an.

In diesem Tutorial bauen wir einen Todo-Manager-MCP-Server mit Benutzer-Authentifizierung (Authentifizierung) und Autorisierung (Autorisierung). Nach der neuesten MCP-Spezifikation agiert unser MCP-Server als OAuth 2.0 Ressourcenserver (Resource Server), der Zugangstokens validiert und berechtigungsbasierte Berechtigungen durchsetzt.

Nach Abschluss dieses Tutorials hast du:

  • ✅ Ein grundlegendes Verständnis, wie du rollenbasierte Zugangskontrolle (RBAC) in deinem MCP-Server einrichtest.
  • ✅ Einen MCP-Server, der als Ressourcenserver agiert und Zugangstokens akzeptiert, die von einem Autorisierungsserver ausgestellt wurden.
  • ✅ Eine funktionierende Implementierung der durch Berechtigungen gesteuerten Zugriffskontrolle für Todo-Operationen.

Überblick​

Das Tutorial umfasst folgende Komponenten:

  • MCP-Client (VS Code): Ein Code-Editor mit eingebauter MCP-Unterstützung, der als OAuth 2.0/OIDC-Client agiert. Er initiiert den Autorisierungs-Flow mit dem Autorisierungsserver und erhält Zugangstokens, um Anfragen an den MCP-Server zu authentifizieren.
  • Autorisierungsserver: Ein OAuth 2.1- oder OpenID Connect-Anbieter, der Benutzeridentitäten verwaltet, Benutzer authentifiziert und Zugangstokens mit passenden Berechtigungen an autorisierte Clients ausstellt.
  • MCP-Server (Ressourcenserver): Nach der neuesten MCP-Spezifikation agiert der MCP-Server als Ressourcenserver im OAuth 2.0-Framework. Er validiert Zugangstokens, die vom Autorisierungsserver ausgestellt wurden, und erzwingt berechtigungsbasierte Berechtigungen für Todo-Operationen.

Diese Architektur folgt dem Standard-OAuth 2.0-Flow, bei dem:

  • VS Code geschützte Ressourcen im Namen des Benutzers anfordert
  • Der Autorisierungsserver den Benutzer authentifiziert und Zugangstokens ausstellt
  • Der MCP-Server Tokens validiert und geschützte Ressourcen basierend auf gewährten Berechtigungen bereitstellt

Hier ist ein Überblicksdiagramm der Interaktion zwischen diesen Komponenten:

Verstehe deinen Autorisierungsserver​

Zugangstokens mit Berechtigungen (Scopes)​

Um rollenbasierte Zugangskontrolle (RBAC) in deinem MCP-Server zu implementieren, muss dein Autorisierungsserver Zugangstokens mit Berechtigungen (Scopes) ausstellen können. Berechtigungen repräsentieren die Rechte, die einem Benutzer gewährt wurden.

Logto bietet RBAC-Unterstützung durch seine API-Ressourcen (gemäß RFC 8707: Resource Indicators for OAuth 2.0) und Rollenfunktionen. So richtest du es ein:

  1. Melde dich bei der Logto Console (oder deiner selbst gehosteten Logto Console) an.

  2. Erstelle API-Ressource und Berechtigungen:

    • Gehe zu "API-Ressourcen"
    • Erstelle eine neue API-Ressource namens "Todo Manager"
    • Füge folgende Berechtigungen hinzu:
      • create:todos: "Neue Todo-Einträge erstellen"
      • read:todos: "Alle Todo-Einträge lesen"
      • delete:todos: "Beliebigen Todo-Eintrag löschen"

  3. Erstelle Rollen (empfohlen für einfachere Verwaltung):

    • Gehe zu "Rollen"
    • Erstelle eine "Admin"-Rolle und weise alle Berechtigungen zu (create:todos, read:todos, delete:todos)
    • Erstelle eine "User"-Rolle und weise nur die Berechtigung create:todos zu

  4. Berechtigungen zuweisen:

    • Gehe zu "Benutzer"
    • Wähle einen Benutzer aus
    • Du kannst entweder:
      • Rollen im Tab "Rollen" zuweisen (empfohlen)
      • Oder Berechtigungen direkt im Tab "Berechtigungen" zuweisen

Die Berechtigungen werden im scope-Anspruch des JWT-Zugangstokens als durch Leerzeichen getrennte Zeichenkette enthalten sein.

Tokens validieren und Berechtigungen prüfen​

Nach der neuesten MCP-Spezifikation agiert der MCP-Server als Ressourcenserver (Resource Server) im OAuth 2.0-Framework. Als Ressourcenserver hat der MCP-Server folgende Aufgaben:

  1. Token-Validierung: Überprüfe die Echtheit und Integrität der von MCP-Clients erhaltenen Zugangstokens
  2. Berechtigungsdurchsetzung: Extrahiere und prüfe die Berechtigungen aus dem Zugangstoken, um zu bestimmen, welche Operationen der Client ausführen darf
  3. Ressourcenschutz: Gebe geschützte Ressourcen (Tools ausführen) nur frei, wenn der Client gültige Tokens mit ausreichenden Berechtigungen vorlegt

Wenn dein MCP-Server eine Anfrage erhält, führt er folgenden Validierungsprozess durch:

  1. Extrahiere das Zugangstoken aus dem Authorization-Header (Bearer-Token-Format)
  2. Validierung der Signatur und Ablaufzeit des Zugangstokens
  3. Extrahiere die Berechtigungen und Benutzerinformationen aus dem validierten Token
  4. Prüfe, ob das Token die erforderlichen Berechtigungen für die angeforderte Operation enthält

Beispiel: Wenn ein Benutzer einen neuen Todo-Eintrag erstellen möchte, muss sein Zugangstoken die Berechtigung create:todos enthalten. So funktioniert der Validierungs-Flow des Ressourcenservers:

Dynamische Client-Registrierung​

Dynamische Client-Registrierung ist für dieses Tutorial nicht erforderlich, kann aber nützlich sein, wenn du den MCP-Client-Registrierungsprozess mit deinem Autorisierungsserver automatisieren möchtest. Siehe Ist Dynamic Client Registration erforderlich? für weitere Details.

Verstehe RBAC im Todo-Manager​

Zu Demonstrationszwecken implementieren wir ein einfaches rollenbasiertes Zugangskontrollsystem (RBAC) in unserem Todo-Manager-MCP-Server. Das zeigt dir die Grundprinzipien von RBAC bei überschaubarer Implementierung.

hinweis

Auch wenn dieses Tutorial RBAC-basierte Berechtigungsverwaltung demonstriert, ist es wichtig zu beachten, dass nicht alle Authentifizierungsanbieter die Berechtigungsverwaltung über Rollen implementieren. Manche Anbieter haben eigene Mechanismen zur Verwaltung von Zugangskontrolle und Berechtigungen.

Tools und Berechtigungen​

Unser Todo-Manager-MCP-Server stellt drei Haupttools bereit:

  • create-todo: Erstelle einen neuen Todo-Eintrag
  • get-todos: Liste alle Todos auf
  • delete-todo: Lösche ein Todo anhand der ID

Zur Zugriffskontrolle auf diese Tools definieren wir folgende Berechtigungen:

  • create:todos: Erlaubt das Erstellen neuer Todo-Einträge
  • delete:todos: Erlaubt das Löschen bestehender Todo-Einträge
  • read:todos: Erlaubt das Abfragen und Abrufen aller Todo-Einträge

Rollen und Berechtigungen​

Wir definieren zwei Rollen mit unterschiedlichen Zugriffsrechten:

Rollecreate:todosread:todosdelete:todos
Admin✅✅✅
User✅
  • User: Ein normaler Benutzer, der Todo-Einträge erstellen und nur seine eigenen Todos ansehen oder löschen kann
  • Admin: Ein Administrator, der alle Todo-Einträge erstellen, ansehen und löschen kann, unabhängig vom Eigentümer

Ressourcenbesitz​

Obwohl die obige Berechtigungstabelle die expliziten Berechtigungen jeder Rolle zeigt, gibt es ein wichtiges Prinzip des Ressourcenbesitzes zu beachten:

  • Benutzer haben nicht die Berechtigungen read:todos oder delete:todos, können aber trotzdem:
    • Ihre eigenen Todo-Einträge lesen
    • Ihre eigenen Todo-Einträge löschen
  • Admins haben volle Berechtigungen (read:todos und delete:todos) und können daher:
    • Alle Todo-Einträge im System ansehen
    • Jeden Todo-Eintrag löschen, unabhängig vom Eigentümer

Das demonstriert ein häufiges Muster in RBAC-Systemen, bei dem der Besitz einer Ressource implizite Berechtigungen für eigene Ressourcen gewährt, während administrative Rollen explizite Berechtigungen für alle Ressourcen erhalten.

Mehr erfahren

Um tiefer in RBAC-Konzepte und Best Practices einzutauchen, siehe Mastering RBAC: A Comprehensive Real-World Example.

Autorisierung in deinem Anbieter konfigurieren​

Um das oben beschriebene Zugangskontrollsystem zu implementieren, musst du deinen Autorisierungsserver so konfigurieren, dass er die erforderlichen Berechtigungen unterstützt. So geht es mit verschiedenen Anbietern:

Logto bietet RBAC-Unterstützung durch seine API-Ressourcen und Rollenfunktionen. So richtest du es ein:

  1. Melde dich bei der Logto Console (oder deiner selbst gehosteten Logto Console) an.

  2. Erstelle API-Ressource und Berechtigungen:

    • Gehe zu "API-Ressourcen"
    • Erstelle eine neue API-Ressource namens "Todo Manager" und verwende http://localhost:3001/ als Ressourcenindikator.
      • Wichtig: Der Ressourcenindikator muss mit der URL deines MCP-Servers übereinstimmen. Für dieses Tutorial verwenden wir http://localhost:3001/, da unser MCP-Server auf Port 3001 läuft. In Produktion verwende deine tatsächliche MCP-Server-URL (z. B. https://your-mcp-server.example.com/).
    • Erstelle folgende Berechtigungen:
      • create:todos: "Neue Todo-Einträge erstellen"
      • read:todos: "Alle Todo-Einträge lesen"
      • delete:todos: "Beliebigen Todo-Eintrag löschen"

  3. Erstelle Rollen (empfohlen für einfachere Verwaltung):

    • Gehe zu "Rollen"
    • Erstelle eine "Admin"-Rolle und weise alle Berechtigungen zu (create:todos, read:todos, delete:todos)
    • Erstelle eine "User"-Rolle und weise nur die Berechtigung create:todos zu
    • Wechsle auf der Detailseite der "User"-Rolle zum Tab "Allgemein" und setze die "User"-Rolle als "Standardrolle".

  4. Benutzerrollen und Berechtigungen verwalten:

    • Für neue Benutzer:
      • Sie erhalten automatisch die "User"-Rolle, da wir sie als Standardrolle gesetzt haben
    • Für bestehende Benutzer:
      • Gehe zu "Benutzerverwaltung"
      • Wähle einen Benutzer aus
      • Weise dem Benutzer Rollen im Tab "Rollen" zu
Programmatische Rollenverwaltung

Du kannst auch die Management API von Logto verwenden, um Benutzerrollen programmatisch zu verwalten. Das ist besonders nützlich für automatisiertes Benutzer-Management oder beim Bau von Admin-Panels.

Beim Anfordern eines Zugangstokens wird Logto die Berechtigungen im scope-Anspruch des Tokens basierend auf den Rollenberechtigungen des Benutzers eintragen.

Abschließender Schrägstrich im Ressourcenindikator

Füge immer einen abschließenden Schrägstrich (/) im Ressourcenindikator hinzu. Aufgrund eines aktuellen Bugs im offiziellen MCP-SDK fügen Clients, die das SDK verwenden, beim Starten von Auth-Anfragen automatisch einen Schrägstrich an Ressourcenkennungen an. Wenn dein Ressourcenindikator keinen Schrägstrich enthält, schlägt die Ressourcenvalidierung für diese Clients fehl. (VS Code ist von diesem Bug nicht betroffen.)

Nach der Konfiguration deines Autorisierungsservers erhalten Benutzer Zugangstokens mit ihren gewährten Berechtigungen. Der MCP-Server verwendet diese Berechtigungen, um zu bestimmen:

  • Ob ein Benutzer neue Todos erstellen darf (create:todos)
  • Ob ein Benutzer alle Todos (read:todos) oder nur seine eigenen ansehen darf
  • Ob ein Benutzer beliebige Todos (delete:todos) oder nur seine eigenen löschen darf

MCP-Server einrichten​

Wir verwenden die offiziellen MCP-SDKs, um unseren Todo-Manager-MCP-Server zu erstellen.

Neues Projekt erstellen​

Richte ein neues Node.js-Projekt ein:

mkdir mcp-server
cd mcp-server
npm init -y # Oder verwende `pnpm init`
npm pkg set type="module"
npm pkg set main="todo-manager.ts"
npm pkg set scripts.start="node --experimental-strip-types todo-manager.ts"
hinweis

Wir verwenden TypeScript in unseren Beispielen, da Node.js v22.6.0+ TypeScript nativ mit dem Flag --experimental-strip-types ausführen kann. Wenn du JavaScript verwendest, ist der Code ähnlich – stelle nur sicher, dass du Node.js v22.6.0 oder neuer nutzt. Siehe Node.js-Dokumentation für Details.

MCP-SDK und Abhängigkeiten installieren​

npm install @modelcontextprotocol/sdk express zod

Oder ein anderes Paketmanagement-Tool deiner Wahl, wie pnpm oder yarn.

MCP-Server erstellen​

Erstelle eine Datei namens todo-manager.ts und füge folgenden Code hinzu:

[Der Code bleibt unverändert, siehe oben.]

Starte den Server mit:

npm start

Integration mit deinem Autorisierungsserver​

Für diesen Abschnitt gibt es einige Überlegungen:

Die Issuer-URL deines Autorisierungsservers

Dies ist normalerweise die Basis-URL deines Autorisierungsservers, z. B. https://auth.example.com. Manche Anbieter haben einen Pfad wie https://example.logto.app/oidc, prüfe daher die Dokumentation deines Anbieters.

Wie du die Metadaten des Autorisierungsservers abrufst
  • Wenn dein Autorisierungsserver dem OAuth 2.0 Authorization Server Metadata oder OpenID Connect Discovery entspricht, kannst du die eingebauten Utilities von MCP Auth verwenden, um die Metadaten automatisch abzurufen.
  • Wenn dein Autorisierungsserver diese Standards nicht unterstützt, musst du die Metadaten-URL oder Endpunkte manuell in der MCP-Server-Konfiguration angeben. Prüfe die Dokumentation deines Anbieters für die spezifischen Endpunkte.
Wie du den MCP-Client in deinem Autorisierungsserver registrierst
  • Wenn dein Autorisierungsserver Dynamic Client Registration unterstützt, kannst du diesen Schritt überspringen, da sich der MCP-Client automatisch registriert.
  • Wenn dein Autorisierungsserver Dynamic Client Registration nicht unterstützt, musst du den MCP-Client manuell registrieren.
Verstehe Token-Request-Parameter

Beim Anfordern von Zugangstokens von verschiedenen Autorisierungsservern gibt es verschiedene Ansätze, um die Zielressource und Berechtigungen anzugeben. Hier die wichtigsten Muster:

  • Ressourcenindikator-basiert:

    • Verwendet den resource-Parameter, um die Ziel-API anzugeben (siehe RFC 8707: Resource Indicators for OAuth 2.0)
    • Häufig in modernen OAuth 2.0-Implementierungen
    • Beispielanfrage: 
      {
  "resource": "http://localhost:3001/",
  "scope": "create:todos read:todos"
}
    • Der Server stellt Tokens aus, die speziell an die angeforderte Ressource gebunden sind

  • Audience-basiert:

    • Verwendet den audience-Parameter, um den beabsichtigten Token-Empfänger anzugeben
    • Ähnlich wie Ressourcenindikatoren, aber mit anderen Semantiken
    • Beispielanfrage: 
      {
  "audience": "todo-api",
  "scope": "create:todos read:todos"
}

  • Rein berechtigungsbasiert:

    • Verwendet ausschließlich Berechtigungen ohne resource/audience-Parameter
    • Traditioneller OAuth 2.0-Ansatz
    • Beispielanfrage: 
      {
  "scope": "todo-api:create todo-api:read openid profile"
}
    • Oft werden Präfixe verwendet, um Berechtigungen zu gruppieren
    • Häufig in einfacheren OAuth 2.0-Implementierungen
Best Practices
  • Prüfe die Dokumentation deines Anbieters auf unterstützte Parameter
  • Manche Anbieter unterstützen mehrere Ansätze gleichzeitig
  • Ressourcenindikatoren bieten bessere Sicherheit durch Audience-Restriktion
  • Verwende Ressourcenindikatoren, wenn verfügbar, für bessere Zugangskontrolle

Auch wenn jeder Anbieter eigene Anforderungen hat, führen dich die folgenden Schritte durch die Integration von VS Code und MCP-Server mit anbieter-spezifischen Konfigurationen.

MCP-Client als Drittanbieter-App registrieren​

Die Integration des Todo-Managers mit Logto ist unkompliziert, da es ein OpenID Connect-Anbieter ist, der Ressourcenindikatoren und Berechtigungen unterstützt. So kannst du deine Todo-API mit http://localhost:3001/ als Ressourcenindikator absichern.

Da Logto Dynamic Client Registration noch nicht unterstützt, musst du deinen MCP-Client (VS Code) manuell als Drittanbieter-App in deinem Logto-Tenant registrieren:

  1. Melde dich bei der Logto Console (oder deiner selbst gehosteten Logto Console) an.
  2. Navigiere zu Anwendungen > Drittanbieter-Apps und klicke auf "Anwendung erstellen".
  3. Wähle Native App als Anwendungstyp.
  4. Fülle die Anwendungsdetails aus:
    • Anwendungsname: Gib einen Namen für deine Anwendung ein, z. B. "MCP Client".
    • Beschreibung: Gib eine Beschreibung ein, z. B. "MCP-Client für VS Code".
  5. Setze folgende Redirect-URIs für VS Code: 
    http://127.0.0.1
https://vscode.dev/redirect
  6. Klicke auf "Änderungen speichern".
  7. Gehe zum Tab Berechtigungen der App, füge unter Benutzer die Berechtigungen create:todos, read:todos und delete:todos aus der zuvor erstellten Todo Manager-API-Ressource hinzu.
  8. Im oberen Bereich siehst du den Wert "App ID". Kopiere ihn für später.

MCP Auth einrichten​

Installiere zuerst das MCP Auth SDK in deinem MCP-Server-Projekt.

pnpm add mcp-auth

Jetzt müssen wir MCP Auth im MCP-Server initialisieren. Im geschützten Ressourcenmodus musst du deine Ressourcenmetadaten einschließlich der Autorisierungsserver konfigurieren.

Es gibt zwei Möglichkeiten, Autorisierungsserver zu konfigurieren:

  • Vorab abgerufen (empfohlen): Verwende fetchServerConfig(), um die Metadaten vor der Initialisierung von MCPAuth abzurufen. So wird die Konfiguration beim Start validiert.
  • On-Demand-Discovery: Gib nur issuer und type an – Metadaten werden bei Bedarf abgerufen. Das ist nützlich für Edge-Runtimes (wie Cloudflare Workers), bei denen asynchrone Top-Level-Fetches nicht erlaubt sind.

Geschützte Ressourcenmetadaten konfigurieren​

Zuerst benötigst du die Issuer-URL deines Autorisierungsservers:

In Logto findest du die Issuer-URL auf der Anwendungsdetailseite in der Logto Console unter "Endpoints & Credentials / Issuer endpoint". Sie sollte etwa so aussehen: https://my-project.logto.app/oidc.

Jetzt konfiguriere die Protected Resource Metadata beim Erstellen der MCP Auth-Instanz:

[Der Code bleibt unverändert, siehe oben.]

MCP-Server aktualisieren​

Fast geschafft! Jetzt aktualisieren wir den MCP-Server, um die MCP Auth-Route und Middleware-Funktion anzuwenden und die berechtigungsbasierte Zugriffskontrolle für die Todo-Manager-Tools basierend auf den Benutzerberechtigungen zu implementieren.

Jetzt Protected Resource Metadata-Routen anwenden, damit MCP-Clients die erwarteten Ressourcenmetadaten vom MCP-Server abrufen können.

[Der Code bleibt unverändert, siehe oben.]

Jetzt wenden wir die MCP Auth-Middleware auf den MCP-Server an. Diese Middleware übernimmt Authentifizierung und Autorisierung für eingehende Anfragen und stellt sicher, dass nur autorisierte Benutzer Zugriff auf die Todo-Manager-Tools haben.

[Der Code bleibt unverändert, siehe oben.]

Jetzt können wir die Implementierung der Tools aktualisieren.

[Der Code bleibt unverändert, siehe oben.]

Jetzt erstelle den "Todo-Service", der im obigen Code verwendet wird, um die zugehörige Funktionalität zu implementieren:

Erstelle die Datei todo-service.ts für den Todo-Service:

[Der Code bleibt unverändert, siehe oben.]

Herzlichen Glückwunsch! Wir haben erfolgreich einen vollständigen MCP-Server mit Authentifizierung (Authentifizierung) und Autorisierung (Autorisierung) implementiert!

info

Siehe das MCP Auth Node.js SDK Repository für den vollständigen Code des MCP-Servers (OIDC-Version).

Checkpoint: Die todo-manager-Tools ausführen​

Starte deinen MCP-Server neu und verbinde VS Code damit. So verbindest du dich mit Authentifizierung:

  1. Drücke in VS Code Command + Shift + P (macOS) oder Ctrl + Shift + P (Windows/Linux), um die Befehlspalette zu öffnen.
  2. Tippe MCP: Add Server... und wähle es aus.
  3. Wähle HTTP als Servertyp.
  4. Gib die MCP-Server-URL ein: http://localhost:3001
  5. Nach dem Start einer OAuth-Anfrage fordert dich VS Code auf, die App ID einzugeben. Gib die App ID ein, die du von deinem Autorisierungsserver kopiert hast.
  6. Da wir kein App Secret haben (es ist ein Public Client), drücke einfach Enter, um zu überspringen.
  7. Schließe den Anmeldeprozess im Browser ab.

Sobald du dich angemeldet hast und zu VS Code zurückkehrst, wiederhole die Aktionen aus dem vorherigen Checkpoint, um die Todo-Manager-Tools auszuführen. Diesmal kannst du die Tools mit deiner authentifizierten Benutzeridentität verwenden. Das Verhalten der Tools hängt von den Rollen und Berechtigungen ab, die deinem Benutzer zugewiesen sind:

  • Wenn du als User (nur mit create:todos-Berechtigung) angemeldet bist:

    • Du kannst neue Todos mit dem Tool create-todo erstellen
    • Du kannst nur deine eigenen Todos ansehen und löschen
    • Du kannst keine Todos anderer Benutzer sehen oder löschen

  • Wenn du als Admin (mit allen Berechtigungen: create:todos, read:todos, delete:todos) angemeldet bist:

    • Du kannst neue Todos erstellen
    • Du kannst alle Todos im System mit dem Tool get-todos ansehen
    • Du kannst beliebige Todos mit dem Tool delete-todo löschen, unabhängig davon, wer sie erstellt hat

Du kannst diese unterschiedlichen Berechtigungsstufen testen, indem du:

  1. Die Verbindung zum MCP-Server trennst (Serverkonfiguration in VS Code entfernen)
  2. Dich mit einem anderen Benutzerkonto anmeldest, das andere Rollen/Berechtigungen hat
  3. Die gleichen Tools erneut ausprobierst, um zu sehen, wie sich das Verhalten je nach Benutzerberechtigungen ändert

Das zeigt, wie rollenbasierte Zugangskontrolle (RBAC) in der Praxis funktioniert, wobei verschiedene Benutzer unterschiedliche Zugriffsrechte auf die Funktionen des Systems haben.

info

Siehe das MCP Auth Node.js SDK Repository für den vollständigen Code des MCP-Servers (OIDC-Version).

Abschließende Hinweise​

Herzlichen Glückwunsch! Du hast das Tutorial erfolgreich abgeschlossen. Lass uns zusammenfassen, was wir gemacht haben:

  • Einen grundlegenden MCP-Server mit Todo-Management-Tools (create-todo, get-todos, delete-todo) eingerichtet
  • Rollenbasierte Zugangskontrolle (RBAC) mit unterschiedlichen Berechtigungsstufen für Benutzer und Admins implementiert
  • Den MCP-Server mit einem Autorisierungsserver über MCP Auth integriert
  • VS Code so konfiguriert, dass Benutzer authentifiziert werden und Zugangstokens mit Berechtigungen zum Aufrufen der Tools verwenden

Sieh dir weitere Tutorials und die Dokumentation an, um das Beste aus MCP Auth herauszuholen.