Testen von Login und Zugriff mit MCP Jam: None, Bearer, OAuth with credentials, Default OAuth

1. MCP Jam als Labor für die Autorisierung

MCP Jam ist nicht „noch ein komisches Tool“, sondern Ihr Laboraufbau, der die Rolle eines MCP‑Clients spielen kann. Im Kern emuliert es das Verhalten von ChatGPT beim Arbeiten mit einem MCP‑Server: Es kann .well-known/oauth-protected-resource lesen, einen OAuth‑Flow starten, Tokens an Anfragen anhängen und anzeigen, was genau schiefgelaufen ist.

Ein sehr wichtiger Praxispunkt: Wenn Sie einen erfolgreichen Default OAuth‑Flow in MCP Jam erreicht haben, sind Sie zu etwa 80 % bereit für die Integration mit der echten ChatGPT‑App. Alles, was ChatGPT beim Verknüpfen des Kontos (Linking) macht, kann Jam bereits – nur mit transparenteren Logs und Buttons.

In der vorherigen Vorlesung haben wir die Basisautorisierung für unseren Lern‑MCP‑Server GiftGenius eingerichtet: Wir haben die Tokenprüfung (JWT oder Introspection) gewählt, .well-known/oauth-protected-resource implementiert und eine Middleware gebaut, die Tools schützt. Jetzt schauen wir, wie sich das alles in MCP Jam in verschiedenen Autorisierungsmodi verhält.

Unser Ziel in dieser Vorlesung ist es, Folgendes zu lernen:

• bewusst zwischen Autorisierungsmodi in Jam zu wechseln (None, Bearer, OAuth with credentials, Default OAuth);
• zu verstehen, was Jam in jedem Modus an den MCP‑Server sendet;
• zu diagnostizieren, welcher Teil des Systems kaputt ist: MCP Server, Auth Server oder Metadaten;
• zu prüfen, dass geschützte Tools nur mit Token funktionieren, offene hingegen auch ohne.

2. Unser Lern‑MCP‑Server: Was wir testen

Damit es nicht abstrakt bleibt, erinnern wir kurz an den Kontext. Wir führen die Geschichte mit unserer Lern‑App GiftGenius fort – das ist eine ChatGPT‑App, die beim Finden von Geschenken hilft und dem Nutzer seine Bestellungen und Wunschlisten anzeigt.

Auf der MCP‑Serverseite haben wir bereits:

• ein offenes Tool, z. B. search_gifts – es kann anonym aufgerufen werden;
• ein geschütztes Tool, z. B. list_user_orders – es darf nur für authentifizierte Nutzer funktionieren und den Scope mcp:tools verlangen.

Der Server kann:

• /.well-known/oauth-protected-resource veröffentlichen;
• das Token prüfen (JWT oder via Introspection – Sie haben in der vorherigen Vorlesung einen Ansatz gewählt);
• aus dem Token sub (User‑ID), scope, aud extrahieren und an die Tool‑Handler übergeben.

Eine typische Tokenprüf‑Middleware in Node.js/TypeScript kann so aussehen:

// middleware/auth.ts
export function requireScope(requiredScope: string) {
  return async (req: any, res: any, next: () => void) => {
    const header = req.headers["authorization"];
    if (!header?.startsWith("Bearer ")) {
      res
        .status(401)
        .set(
          "WWW-Authenticate",
          `Bearer realm="mcp", resource_metadata="${process.env.BASE_URL}/.well-known/oauth-protected-resource", scope="${requiredScope}"`
        )
        .json({ error: "unauthorized" });
      return;
    }

    // hier prüfen Sie bereits das Token (Signatur, exp, aud, scope ...)
    // und legen das Ergebnis in req.user ab
    next();
  };
}

Diese Middleware wird vor den geschützten MCP‑Tools verwendet. Wenn kein Token vorhanden ist, geben wir 401 und einen korrekten WWW-Authenticate mit resource_metadata zurück, wie es die MCP‑Authorization‑Spezifikation verlangt. Eine detaillierte Analyse der Tokenprüfung und der Hilfsfunktionen haben Sie bereits in der vorherigen Vorlesung gemacht; hier verwenden wir dies als gegeben.

3. Autorisierungsmodi in MCP Jam: Überblick

In MCP Jam gibt es mehrere Autorisierungsmodi für die Verbindung zum MCP‑Server. Sie entsprechen typischen OAuth‑Mustern: vom vollständigen Fehlen eines Tokens bis hin zu einem vollwertigen Authorization Code + PKCE.

Kurz zusammengefasst:

1. None (No Auth) – Jam fügt überhaupt keinen Authorization‑Header hinzu. Das ist anonymer Zugriff. Passt für offene MCP‑Server und die Prüfung, dass geschlossene Ressourcen korrekt mit 401 und WWW-Authenticate ablehnen.
2. Bearer Token – Jam fügt Authorization: Bearer <Token> hinzu, den Sie manuell in der Oberfläche eintragen. Geeignet für schnelle Checks: Das Token wurde bereits irgendwo geholt (curl, Keycloak‑UI), und Sie möchten das Verhalten der MCP‑Ressource testen.
3. OAuth with credentials (Client Credentials) – Jam holt das Token selbst via client_credentials beim Auth Server, indem es die angegebenen Client ID und Secret nutzt. Das ist der Modus eines „confidential client“, eher eine Server‑zu‑Server‑Autorisierung ohne Nutzerbeteiligung.
4. Default OAuth (Authorization Code + PKCE) – der Hauptmodus für ChatGPT‑ähnliche Clients (Public Client ohne Secret). Jam liest resource_metadata, findet den Auth Server, öffnet den Browser mit /authorize, führt den PKCE‑Flow aus und erhält ein Nutzer‑Token.

Zur Anschaulichkeit fassen wir das in einer Tabelle zusammen.

Nun gehen wir jeden Modus durch und schauen, wie wir unseren GiftGenius‑MCP‑Server damit testen.

4. Modus None: Prüfen, dass der Server korrekt verweigert

Beginnen wir mit dem einfachsten Modus: keinerlei Autorisierung.

In MCP Jam wählen Sie Ihren Server (z. B. http://localhost:4000/mcp) und stellen in den Verbindungs‑Einstellungen den Autorisierungsmodus auf None.

Was dabei passiert:

• Jam stellt die MCP‑Verbindung her;
• beim Aufruf eines Tools fügt es keinen Authorization‑Header hinzu;
• Sie können beliebige offene Tools aufrufen (z. B. search_gifts);
• beim Aufruf eines geschützten Tools (z. B. list_user_orders) sollte Ihr Server mit 401 Unauthorized antworten.

Wichtig ist, dass der Server bei diesem 401 einen korrekten WWW-Authenticate hinzufügt. Ein Beispiel einer Antwort mit zusätzlichen Feldern realm und scope, nahe an den Empfehlungen von OpenAI und der MCP‑Authorization‑Spec:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://giftgenius.example.com/.well-known/oauth-protected-resource",
  scope="mcp:tools"
Content-Type: application/json

{"error": "unauthorized"}

Wenn Jam eine solche Antwort sieht, versteht es: Die Ressource ist geschützt, hier sind die Metadaten zu holen (resource_metadata) und diese Scopes werden erwartet. Im Modus None zeigt es Ihnen lediglich den Fehler an, im Modus Default OAuth folgt es automatisch dem angegebenen resource_metadata und startet den OAuth‑Flow.

Aus Debug‑Sicht prüfen Sie im Modus None:

• dass offene Tools auch ohne Token funktionieren;
• dass geschützte Tools niemals anonym ausgeführt werden;
• dass der Header WWW-Authenticate der Spezifikation entspricht (enthält Bearer und resource_metadata).

Das klingt trivial, aber sehr viele Probleme beginnen damit, dass 401 ohne WWW-Authenticate oder mit einem falschen Parameter darin zurückgegeben wird (z. B. das veraltete resource_metadata_uri statt des aktuellen resource_metadata).

5. Modus Bearer Token: schneller Test der Resource‑Server‑Logik

Der nächste Schritt ist ein Modus, in dem Sie bereits ein gültiges Token haben (außerhalb von Jam erhalten) und genau die Logik des Resource Servers testen möchten: Ob er dieses Token korrekt akzeptiert/ablehnt, ob er mit Scope und Audience korrekt arbeitet und sub mit dem Nutzer Ihres Dienstes verknüpft.

In MCP Jam schalten Sie auf Bearer Token und fügen in das Token‑Feld beispielsweise ein:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Jam wird nun zu jeder MCP‑Anfrage den Header hinzufügen:

Authorization: Bearer eyJhbGciOi...

Ihr MCP‑Server nimmt die Anfrage an, läuft durch die Middleware requireScope("mcp:tools"), dekodiert das JWT und prüft die Claims. Typischen Prüfcode kann man vereinfacht so schreiben:

// auth/verifyToken.ts
import jwt from "jsonwebtoken";

export function verifyToken(header: string) {
  const token = header.replace("Bearer ", "");
  const payload = jwt.verify(token, process.env.JWT_PUBLIC_KEY!);
  // hier können Sie aud, scope usw. prüfen
  return payload as { sub: string; scope?: string };
}

Und in der Middleware verwenden:

// innerhalb von requireScope
const payload = verifyToken(header);
if (!payload.scope?.includes(requiredScope)) {
  res.status(403).json({ error: "insufficient_scope" });
  return;
}
(req as any).user = { id: payload.sub };
next();

Im Bearer‑Modus können Sie experimentieren:

• ein Token ohne den benötigten Scope einfügen und sicherstellen, dass der Server mit 403/401 antwortet;
• ein Token mit falscher aud einfügen und sehen, dass der Server es ablehnt;
• ein abgelaufenes Token einfügen, um den Fehler invalid_token zu prüfen.

Das ist der Modus des lokalen „Stresstestens“ der Resource‑Server‑Logik ohne UI‑Login und PKCE. Alles, was Sie hier prüfen, gilt eins zu eins auch für Tokens, die ChatGPT oder Jam im Modus Default OAuth erhalten werden.

6. Modus OAuth with credentials (Client Credentials): Token „im Namen der Anwendung“

Nun ein seltenerer, aber fürs Verständnis nützlicher Modus: OAuth with credentials, also der client_credentials‑Grant. In Jam geben Sie an:

• Client ID
• Client Secret
• benötigte Scopes (z. B. mcp:tools)

Jam führt eine Anfrage an den token_endpoint Ihres Auth‑Servers etwa in dieser Form aus:

POST /oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_id=<ID>&
client_secret=<SECRET>&
scope=mcp:tools

Der Auth Server gibt ein Token aus, in dem sub üblicherweise den Client selbst bedeutet (z. B. sub = "mcp-jam-test-client") und nicht einen konkreten Nutzer. Jam verwendet dieses Token dann als gewöhnlichen Bearer.

Wofür das in der MCP‑Welt nützlich sein kann:

• Service‑/Admin‑Tools, die nicht an einen konkreten Nutzer gebunden sind (z. B. Log‑Export, Health‑Check, Support);
• Prüfen, dass der MCP‑Server Nutzer‑Tokens und „Client“‑Tokens unterscheiden kann, wenn Ihre Businesslogik das berücksichtigt.

Im Kontext von ChatGPT‑Apps wird dieser Modus normalerweise nicht genutzt, weil ChatGPT als Public Client keine Secrets speichert (und ein Public Client per Definition kein client_secret haben sollte). In Jam hilft er jedoch, den Unterschied zu sehen zwischen:

• „Ich habe einfach ein fertiges Token untergeschoben“ (Bearer‑Modus);
• „Jam hat das Token selbst mit Client‑Zugangsdaten geholt“ (OAuth with credentials).

Auf dem Lernserver kann man z. B. ein spezielles MCP‑Tool admin_list_all_orders schaffen, das nur mit einem Token mit grant_type=client_credentials und entsprechender Rolle zugänglich ist. Das ist kein Pflichtteil dieser Vorlesung, aber ein nützliches Experiment.

7. Modus Default OAuth: vollständiger Authorization Code + PKCE, wie bei ChatGPT

Jetzt der Star des Programms: Default OAuth. Genau dieser Modus kommt dem am nächsten, was ChatGPT beim Verknüpfen des Kontos Ihrer App tut. Der Client liest resource_metadata, geht zum Auth Server, öffnet dem Nutzer die Login‑Seite, erhält einen Authorization Code und tauscht ihn gemäß Authorization Code + PKCE S256 gegen ein Access Token.

Sehen wir uns die Abfolge der Schritte an. Zur Veranschaulichung – ein Diagramm.

sequenceDiagram
    participant Jam as MCP Jam (Client)
    participant RS as MCP Server (Resource)
    participant PRM as /.well-known/oauth-protected-resource
    participant AS as Auth Server (Keycloak/Auth0)
    
    Jam->>RS: Aufruf eines geschützten Tools (ohne Token)
    RS-->>Jam: 401 + WWW-Authenticate (resource_metadata=PRM)
    Jam->>PRM: GET /.well-known/oauth-protected-resource
    PRM-->>Jam: JSON mit resource, authorization_servers, scopes_supported ...
    Jam->>AS: GET /authorize?client_id=...&code_challenge=...&scope=...
    Note right of AS: Benutzer meldet sich an und stimmt zu
    AS-->>Jam: Redirect mit authorization_code
    Jam->>AS: POST /token (code + code_verifier)
    AS-->>Jam: { access_token, scope, expires_in, ... }
    Jam->>RS: Tool-Aufruf mit Authorization: Bearer <access_token>
    RS-->>Jam: Erfolgreiches Tool-Ergebnis

Was Sie in diesem Modus prüfen sollten:

1. Korrekte 401/WWW-Authenticate‑Antwort vom MCP‑Server. Wenn der Server resource_metadata nicht liefert oder eine falsche URL zurückgibt, kann Jam die PRM nicht lesen und den OAuth‑Flow nicht starten.
2. Valides Dokument .well-known/oauth-protected-resource. Es muss korrekte resource‑, authorization_servers‑, scopes_supported‑ usw. Angaben enthalten, damit Jam versteht, wohin es für Tokens gehen und welche Scopes es anfragen soll.
3. Richtige Konfiguration des Auth Servers.
   • Authorization Code Flow mit PKCE S256 ist aktiviert.
   • Die Client ID entspricht dem, was in der PRM erwartet wird (oder wird via DCR – Dynamic Client Registration – registriert).
   • Der Redirect‑URI im Auth Server stimmt exakt mit dem überein, den Jam verwendet.
4. PKCE S256. Jam bildet einen code_challenge und erwartet, dass der Auth Server die Methode S256 unterstützt. Wenn PKCE deaktiviert ist oder nur „plain“ unterstützt wird, bricht der Flow zusammen.
5. Scopes und Audience. Der Auth Server muss ein Token mit der benötigten aud und den angeforderten Scopes (mcp:tools usw.) ausgeben, und der MCP‑Server muss sie prüfen.

Als Ergebnis eines erfolgreichen Default OAuth erhalten Sie:

• in Jam – eine Verbindung zum MCP‑Server, bei der das geschützte Tool list_user_orders genau die Daten für den Nutzer zurückgibt, mit dem Sie sich am Auth Server angemeldet haben;
• in den Logs des Auth Servers – einen erfolgreichen Authorize‑ und Token‑Austausch;
• in den Logs des MCP‑Servers – erfolgreiche Tokenvalidierung und Extraktion von sub.

Für das Debuggen hilft es oft, einen einfachen Logger in den Tool‑Handler einzubauen, um sicherzugehen, dass Sie die userId aus dem Token tatsächlich sehen:

// im Handler des MCP-Tools list_user_orders
export async function listUserOrders(args: any, context: any) {
  const user = context.user as { id: string };
  console.log("[MCP] listUserOrders for user", user.id);
  // danach geben Sie die Bestellungen dieses Benutzers zurück
}

8. Wo etwas kaputtgeht: Diagnose nach Modi

Besprechen wir nun, wie man anhand der Symptome in MCP Jam erkennt, wo genau das Problem liegt: im MCP‑Server, im Auth Server oder in den Metadaten. Dieser Abschnitt ist eine Art Diagnose‑Checkliste nach Modi.

Wenn im Modus None:

Sie rufen ein geschütztes Tool auf, der Server antwortet:

• 200 OK und führt die Aktion sogar ohne Token aus – dann fehlt Ihnen die Tokenprüfung vor diesem Tool. Sie müssen eine Middleware oder die Scope‑Prüfung hinzufügen.
• 401, aber ohne WWW-Authenticate oder mit fehlerhaftem resource_metadata – Jam erfährt nicht, wo es die Metadaten holen soll, und kann Default OAuth nicht starten. Korrigieren Sie den Header nach dem obigen Beispiel.

Wenn im Modus Bearer Token:

• Jam erhält stabil 401/403, sogar mit einem Token, von dem Sie sicher sind, dass es beim direkten Aufruf (via curl oder Postman) gültig ist. Höchstwahrscheinlich stimmt etwas in der Resource‑Server‑Logik nicht: falsche Prüfung von aud/scope oder der falsche öffentliche Schlüssel zur JWT‑Signaturprüfung.
• Wenn das Bearer‑Token in Jam funktioniert, später aber im Default OAuth nicht – dann liegt das Problem nicht im MCP‑Server, sondern im Auth Server oder in der PRM: Das Token aus Default OAuth unterscheidet sich bezüglich scope/aud von dem, das Sie manuell getestet haben.

Wenn im Modus OAuth with credentials:

• Wenn Jam kein Token erhalten kann (Fehler beim Schritt /token) – suchen Sie die Ursache in der Client‑Konfiguration im Auth Server (falsches Secret, nicht erlaubtes client_credentials oder verbotener Scope).
• Wenn ein Token vorhanden ist, der MCP‑Server es aber ablehnt – erwartet Ihr Server möglicherweise ein Nutzer‑sub (E‑Mail/ID des Nutzers), im Token steht jedoch nur die Client‑Kennung. Oder aud/scope stimmen nicht mit den Erwartungen überein.

Wenn im Modus Default OAuth:

Das ist das szenarioreichste Setting. Häufige Probleme:

• Falsche Redirect‑URIs. Der Auth Server meldet invalid_redirect_uri oder gibt einfach keinen Code aus. Stellen Sie sicher, dass der URI von Jam ohne überflüssige Slashes und Tippfehler in den Client‑Einstellungen des IdP eingetragen ist.
• Fehlendes oder nicht unterstütztes PKCE. Wenn der Auth Server PKCE verlangt, Jam (oder eine alte Version davon) aber keinen code_challenge schickt, oder umgekehrt – Jam sendet S256, der IdP unterstützt diese Methode aber nicht – sehen Sie invalid_request.
• Nicht übereinstimmende Scopes. In der PRM haben Sie mcp:tools deklariert, dem Client im IdP ist aber nur openid erlaubt, oder umgekehrt – Jam fordert mehr Scopes an, als der IdP ausgeben will.
• Falsche Audience (aud). Das Token wird mit einer aud ausgegeben, die sich von der unterscheidet, die der MCP‑Server erwartet (z. B. URL einer anderen Ressource). Der Server wird es zurecht ablehnen.

Sehr wichtig ist es, die Logs an drei Stellen lesen zu lernen:

• MCP Jam – Fehler beim Parsen der PRM und bei HTTP‑Anfragen an den Auth Server;
• Auth Server – Logs von /authorize und /token verraten, was abgelehnt wird;
• MCP‑Server – Gründe für Token‑Ablehnungen (invalid_token, insufficient_scope, wrong_audience).

9. Was hat das mit der realen ChatGPT‑App zu tun

Warum verbringen wir so viel Zeit mit Jam und rennen nicht sofort in den Developer Mode von ChatGPT? Weil Jam genau der Laboraufbau ist: Es gibt Ihnen die Kontrolle über die Autorisierungsmodi und zeigt die gesamte innere Abfolge des Flows.

Wenn Sie Default OAuth in Jam starten und zum Erfolg bringen, bestätigen Sie faktisch:

• .well-known/oauth-protected-resource Ihres MCP‑Servers ist korrekt;
• der Auth Server (Keycloak/Auth0/…) ist richtig konfiguriert;
• Rollen, Scopes, Audience und Claims entsprechen den Erwartungen;
• der MCP‑Server kann das Token prüfen und es dem Nutzer zuordnen.

Ein an denselben MCP‑Server angeschlossenes ChatGPT wird dasselbe tun: PRM lesen, zum Auth Server gehen, ein Token erhalten und Tools mit Authorization: Bearer aufrufen.

Der Unterschied ist, dass Sie in ChatGPT nur das Endergebnis sehen („Konto erfolgreich verknüpft“ oder „irgendetwas ist schiefgelaufen“), während Sie in Jam das ganze Protokoll sehen und Schritt für Schritt verstehen können, wo genau es „schief“ war.

10. Mini‑Praxis: sequentielles Testen unseres GiftGenius‑MCP‑Servers

Fassen wir alles in einem einfachen, sequentiellen Szenario zusammen, das Sie in Ihrem Projekt wiederholen können.

Starten Sie zunächst Ihren MCP‑Server (z. B. pnpm dev:mcp), und vergewissern Sie sich, dass:

• er unter http://localhost:4000/mcp (oder Ihrer URL) lauscht;
• der Endpoint /.well-known/oauth-protected-resource korrekten JSON liefert;
• der Auth Server (Keycloak) läuft und einen konfigurierten Public Client für Jam/ChatGPT hat.

Danach:

1. Modus None.
   Verbinden Sie Jam mit dem MCP‑Server ohne Autorisierung. Prüfen Sie, dass:
   • search_gifts funktioniert;
   • list_user_orders 401 mit korrekt gesetztem WWW-Authenticate zurückgibt.
2. Modus Bearer Token.
   Holen Sie ein Access Token über Keycloak (via UI oder curl). Tragen Sie es in Jam ein, rufen Sie list_user_orders auf und stellen Sie sicher, dass:
   • bei gültigem Token das Tool läuft und die Bestellungen des konkreten Nutzers zurückgibt;
   • bei einem Token ohne mcp:tools oder mit anderer aud – der Server einen Fehler liefert.
3. Modus OAuth with credentials.
   Falls Sie einen Confidential Client haben: Geben Sie client_id und client_secret in Jam an, setzen Sie den benötigten Scope, rufen Sie ein technisches Tool auf (z. B. admin_list_all_orders) und prüfen Sie, dass es nur mit einem solchen Service‑Token funktioniert.
4. Modus Default OAuth.
   Aktivieren Sie Default OAuth, rufen Sie list_user_orders auf. Jam wird:
   • 401 + WWW-Authenticate erhalten,
   • die PRM lesen,
   • den Browser öffnen, in dem Sie sich bei Keycloak anmelden,
   • das Token via Authorization Code + PKCE erhalten,
   • das MCP‑Tool mit dem Token aufrufen, woraufhin Sie Ihre Bestellungen in der Antwort sehen.

Wenn alle vier Modi wie erwartet funktioniert haben – Glückwunsch, Sie haben nicht einfach „irgendetwas mit Keycloak konfiguriert“, sondern verstehen wirklich, wie man den gesamten Auth‑Flow prüft und debuggt.

11. Typische Fehler bei der Arbeit mit MCP Jam und beim Testen der Autorisierung

In der Praxis treten diese Probleme häufig als wiederkehrende Fehlerbilder auf. Im Folgenden einige typische „So bitte nicht“‑Szenarien, damit Sie sie an den Symptomen erkennen.

Fehler Nr. 1: Erwartung, dass ein geschütztes Tool im Modus None funktioniert.
Manchmal schaltet ein Entwickler Jam in den Modus None, ruft list_user_orders auf und wundert sich über 401, entfernt dann „vorsichtshalber“ die Tokenprüfung vom Server. Das Ergebnis: Das MCP‑Tool funktioniert anonym – für Personendaten‑ und Commerce‑Szenarien absolut inakzeptabel. Der Modus None dient dazu zu prüfen, dass der Server korrekt ohne Token verweigert und WWW-Authenticate mit resource_metadata zurückgibt.

Fehler Nr. 2: Vergessener oder fehlerhafter WWW-Authenticate‑Header.
Sehr häufig: Der Server gibt 401 ohne WWW-Authenticate zurück oder mit dem veralteten Parameter resource_metadata_uri. Jam (wie auch ChatGPT) weiß dann nicht, wo es die Protected Resource Metadata holen soll, und Default OAuth startet gar nicht. Minimal ausreichend ist WWW-Authenticate: Bearer resource_metadata="https://.../.well-known/oauth-protected-resource". Die Felder realm und scope sind optional; wichtig ist, resource_metadata nicht zu vergessen.

Fehler Nr. 3: Nur den Bearer‑Modus testen und Default OAuth ignorieren.
Der Entwickler holt manuell ein Token, fügt es in Jam ein, sieht, dass alles funktioniert, und hält die Aufgabe für erledigt. Wenn es dann an die Anbindung des echten ChatGPT geht, stellt sich heraus, dass .well-known nicht korrekt ist, PKCE nicht unterstützt wird, der Redirect‑URI nicht passt und das Linking scheitert. Ein Test im Bearer‑Modus ist notwendig, aber nicht hinreichend. Default OAuth muss zwingend durchgespielt werden, sonst prüfen Sie die Hälfte der wichtigsten Einstellungen von Auth Server und PRM nicht.

Fehler Nr. 4: Versuch, client_credentials dort zu verwenden, wo ein Nutzer‑Token nötig ist.
Mitunter aktiviert ein Entwickler in Jam den Modus OAuth with credentials und beginnt, Tokens per client_credentials zu holen, die er dann für Nutzer‑Tools wie list_user_orders verwendet. Dadurch ist sub im Token die client_id und nicht der echte Nutzer – die Businesslogik verhält sich merkwürdig (z. B. „allgemeine“ Daten anzeigen oder beim Versuch scheitern, einen Nutzer mit dieser ID zu finden). Für ChatGPT‑Szenarien mit echten Nutzern braucht es Authorization Code + PKCE (Default OAuth); client_credentials passt nur für Service‑Aufgaben.

Fehler Nr. 5: Uneinheitliche Scopes und Audience zwischen PRM, Auth Server und MCP‑Server.
In .well-known/oauth-protected-resource haben Sie als Resource https://giftgenius.example.com angegeben und als unterstützte Scopes ["mcp:tools"]. Im Auth Server hat der Client ein Token ohne aud erhalten, während der MCP‑Server bei der Tokenprüfung strikt aud = "https://giftgenius.example.com" und das Vorhandensein von mcp:tools erwartet. Das Ergebnis: Das via Default OAuth erhaltene Token lehnt der MCP‑Server ab, und Sie suchen stundenlang nach „Magie“. Prüfen Sie immer, dass PRM, die Client‑Konfiguration im IdP und die Prüfung in der MCP‑Server‑Middleware sich in Bezug auf audience und scope einig sind.

Fehler Nr. 6: Verwendung einer alten Version von MCP Jam.
Die Spezifikation zu MCP Authorization entwickelt sich aktiv weiter; es entstehen neue Felder (resource_metadata, verbesserter PKCE‑Flow, Hilfs‑Debugger). Wenn Sie eine alte Jam‑Version verwenden, versteht sie möglicherweise neue Felder nicht oder arbeitet mit veralteten Parameternamen. Das führt zu absurd wirkenden Bugs: Sie haben alles nach dem letzten RFC eingerichtet, aber Jam weiß schlicht nicht, was es damit tun soll. Bevor Sie verzweifeln, stellen Sie sicher, dass Jam auf dem aktuellen Stand ist.