Skip to content

OpenAI-MCP: Bindung an den zugelassenen Client

Generated artifact. Do not edit manually.

Generated by: scripts/build_compendia.py Regenerate with: python3 scripts/build_compendia.py --compendium security --web-and-tex Source of truth: docs/security/source/

Sprache / Language: Deutsch (DE) · English (EN) | PDF: Deutsches PDF · English PDF

Kompendium: §1 Datenschutz & Speicherung · §2 OpenAI-MCP-Clientbindung · §3 KI-Verordnung Compliance

2. OpenAI-MCP: Bindung an den zugelassenen Client

Verbindliche Sicherheitsarchitektur für den OpenAI-MCP-Coach

Ursprungsstand: 31. Juli 2026 · Aktualisiert auf die dauerhafte neutrale Plugin-Entscheidung vom 19. Oktober 2026 (skillpilot-coach auf https://mcp-openai.skillpilot.com/mcp, die den früheren Endpunkt https://mcp-coach-v1.skillpilot.com/mcp vor der Verzeichnis-Einreichung ablöst; OAuth-Issuer bleibt https://skillpilot.com/api/openai/v1). Identität, Cutover und Lebenszyklus sind im Versionierungs- und Lebenszyklusplan sowie im Stable-Origin-Runbook festgelegt.

2.1. Schutzziel

Die SkillPilot-ID bleibt das von der lernenden Person verwahrte Geheimnis, an dem ihr Lernstand hängt. Dieses Kapitel behandelt ein davon unabhängiges Schutzziel:

Ein fremder Client darf die lernendenbezogenen OpenAI-V1-MCP-APIs nicht nutzen, auch wenn er den öffentlichen Serververtrag und eine gültige learningSessionId kennt.

Diese Schutzgrenze verändert weder SkillPilot-ID noch Lernziel-, Mastery-, Curriculum- oder Coach-Semantik.

2.2. Vier unabhängige Nachweise

Nachweis Zweck Verbindlicher Mechanismus
SkillPilot-Server Vertraulichkeit und Serverauthentisierung Reguläres HTTPS/TLS am dedizierten Reverse Proxy.
OpenAI-Connector Nur gehostete ChatGPT-Verbindungen aus OpenAIs Zertifikatskette passieren den produktiven Edge-Pfad mTLS mit OpenAI Root CA, Connectors-Intermediate, clientAuth-EKU und exaktem SAN mtls.prod.connectors.openai.com.
Zugelassene MCP-App Nur der explizit zugelassene Client erhält verwendbare OAuth-Tokens Vorregistrierter vertraulicher OAuth-Client (client_secret_basic + Callback-Allowlist + PKCE S256) für den gehosteten Pfad; getrenntes, exakt gepinntes Desktop-CIMD-Profil (S256) ohne Fallback für den nativen Desktop-Pfad.
Aktuelle Lernsession Der konkrete Chat adressiert genau den beim UI-Start gewählten Lernenden Bei jedem Lernen starten frisch erzeugte, exakt 24 Stunden gültige learningSessionId als Pflichtargument jedes fachlichen MCP-Tools.

Für jeden fachlichen Aufruf gilt kumulativ:

gueltiges, client- und resource-gebundenes OAuth Access Token
AND
gueltige explizite learningSessionId
AND (im produktiven gehosteten enforce-Modus)
gueltiges OpenAI-Connector-Clientzertifikat

OAuth authentisiert und autorisiert die App; die Lernsession wählt den Lernenden. Keiner der Nachweise ersetzt den anderen.

2.3. Verbindliches OAuth-Clientprofil

Für den gehosteten ChatGPT-Verzeichnispfad (SkillPilot Coach, technischer Name skillpilot-coach) existiert genau ein vorkonfigurierter vertraulicher OAuth-Client:

  • feste, vom App-Autor vergebene client_id und langes kryptografisch zufälliges client_secret;
  • bytegenau die in der ChatGPT-Appverwaltung hinterlegte Callback-URL;
  • Token-Endpunkt-Authentisierung ausschließlich über client_secret_basic samt Authorization Code mit PKCE ausschließlich S256;
  • exakte öffentliche Resource/Audience https://mcp-openai.skillpilot.com/mcp (keine Doppel-Audiences zum historischen mcp-coach-v1-Ursprung);
  • getrennte Read- und Write-Scopes, kurze Access-Token-Laufzeit, Refresh-Token-Rotation und expliziter Widerruf.

Das Client-Secret liegt ausschließlich an zwei geschützten Orten: (1) in der vertraulichen OAuth-Konfiguration der ChatGPT-App und (2) in der geschützten SkillPilot-Serverumgebung — niemals in Repository, Browserbundle, Startprompt, Chat, MCP-Argumenten, Antworten oder Logs.

Ergänzend ist für die native ChatGPT-Desktop-Integration ein strikt getrenntes, exakt gepinntes öffentliches CIMD-Profil (7yTcOAOqrumX-Client/Callback auf derselben neutralen Resource mit PKCE S256; siehe Native-CIMD-Runbook) autorisiert. Dieses Profil ist niemals ein Fallback einer fehlgeschlagenen vertraulichen Authentisierung. Offene Dynamic Client Registration (DCR), ungepinnte CIMD-Dokumente, beliebige none-Clients und private_key_jwt sind im Produktionsprofil ausgeschlossen.

2.4. OAuth-Ablauf und Ressourcenprüfungen

Der Authorization Server akzeptiert einen Code-Flow nur, wenn (1) client_id exakt einem explizit gepinnten Profil entspricht, (2) redirect_uri bytegenau in dessen Allowlist steht, (3) PKCE S256 vorliegt, (4) resource exakt die aktive MCP-Resource adressiert und (5) nur erlaubte Scopes angefordert werden. Beim Token-Request muss der vertrauliche Client zusätzlich das Secret per HTTP Basic nachweisen.

Bei jedem MCP-Aufruf prüft der Resource Server Signatur bzw. aktive Introspektion, Aussteller (https://skillpilot.com/api/openai/v1), Ablauf und Widerruf, exakte Audience/Resource, exakte Client-ID, den erforderlichen Read-/Write-Scope sowie zusätzlich die explizite gültige learningSessionId. Ein gültiges OAuth-Token darf weder einen Lernenden auswählen noch eine Session anlegen; das OAuth-Subject dient niemals als Identitätsquelle oder Fallback.

2.5. Lernsession als getrennte Anwendungsbindung

Gemäß OAuth- und Lernsession-Vertrag entsteht genau beim Klick auf Lernen starten für jeden Start eine neue zufällige ID (absolut 24 Stunden gültig, niemals verlängert; serverseitig nur als HMAC-Hash mit Lernendenzuordnung gespeichert). Neue fachliche Operationen benötigen mindestens PT1H Restlaufzeit (exakt PT1H ist gültig). Ein bereits committeter Write darf sein gespeichertes Resultat nur bei mindestens PT1H Restlaufzeit, identischem Toolnamen, kanonisch gleichen Argumenten, derselben clientRequestId, verfügbarer gepinnter Workflow-/Curriculumversion und unveränderter Learner-Revision ohne erneute Mutation replayen.

SESSION_REQUIRED, SESSION_RENEWAL_REQUIRED und SESSION_VERSION_UNAVAILABLE sind keine OAuth-Fehler: Der Coach gibt instruction unverändert aus (bzw. den exakten Eintrag aus instructions und ergänzt startUrl nur, falls noch nicht enthalten) — ohne Fachantwort, ohne Retry mit alter Session und ohne neuen OAuth-Flow. Der Lernende startet über Lernen starten im First-Party-WebGUI eine frische Session in einem neuen Chat; die dauerhafte SkillPilot-ID bleibt serverseitig.

2.6. mTLS am MCP-Rand

Gehostete ChatGPT-Connectoren präsentieren beim TLS-Aufbau ein von OpenAI verwaltetes Clientzertifikat. Der dedizierte MCP-vHost vertraut ausschließlich der veröffentlichten OpenAI Root CA und dem Connectors-Intermediate (ohne rotierendes Leaf-Pinning), während ein Loopback-Verifier Kette, clientAuth-EKU und den exakten SAN mtls.prod.connectors.openai.com prüft:

  • observe: Gültige Zertifikate werden als VERIFIED klassifiziert; zertifikatslose Verbindungen passieren vorübergehend bis zur unveränderten OAuth-Schicht und zählen ausschließlich als OBSERVE_NO_CERT (für kontrollierte Integrations- und native Desktop-Tests, kein gehosteter Veröffentlichungszustand). Ungültig präsentierte Zertifikate werden stets abgewiesen.
  • enforce: Externe /mcp-Aufrufe benötigen zwingend VERIFIED. Lediglich unmittelbare Loopback-Socket-Peers dürfen als LOCAL_OPERATOR den unveränderten OAuth-Pfad lokal testen; Internet-Header, Queryparameter oder X-Forwarded-For erzeugen niemals einen Bypass.

Protected-Resource-Metadaten und Domain-Challenge bleiben ohne Clientzertifikat erreichbar. mTLS authentisiert die OpenAI-Infrastruktur und ersetzt weder OAuth noch die Lernsession.

2.7. Fail-Closed-Startbedingungen und Secret-Lebenszyklus

Bei aktiviertem OpenAI-V1-Provider bricht der Serverstart fail-closed ab, sobald eine Bedingung verletzt ist: eigenständiges hochentropisches SKILLPILOT_SIGNING_SECRET mit mindestens 32 Nicht-Leerzeichen (keine Platzhalter/Defaults, niemals geloggt), konsistente gepinnte Client-Konfiguration (feste Client-ID, ausreichend langes Client-Secret ab 32 — vorzugsweise 48+ — Zufallsbytes für client_secret_basic, exakte HTTPS-Callback-Allowlist, PKCE S256, exakte HTTPS-Resource/OAuth-Endpunkte), exakte Modus-Übereinstimmung zwischen Root-Nginx, Backend und interner Klassifikation sowie geschlossene offene DCR/ungepinnte Profile. Port 8787 darf öffentlich nicht erreichbar sein; der Reverse Proxy terminiert TLS und leitet nur freigegebene Pfade an /internal/openai/v1/mcp weiter.

Das OAuth-Client-Secret wird außerhalb des Repositories erzeugt, liegt identisch nur in ChatGPT-Appverwaltung und SkillPilot-Serverumgebung, erscheint nie in Status-/Fehlerausgaben und wird bei Verdacht auf Kompromittierung sofort rotiert (inklusive Token-Widerruf und Neuautorisierung). Eine Rotation von SKILLPILOT_SIGNING_SECRET macht laufende Lernsessions gezielt unauflösbar (geplanter Session-Cutover). Ein Clientwechsel reaktiviert niemals alte Sessions als Identitätsersatz.

2.8. Abnahme-, Negativtests, Restannahmen und Referenzen

Vor einer Freigabe müssen objektiv scheitern: Token-Requests ohne/mit falschem Secret oder fremder Client-ID; nicht gepinnte Methoden (client_secret_post, offene DCR, ungepinnte none/CIMD/private_key_jwt); falsche Callback-URL oder fehlendes/falsches PKCE; fehlende/falsche Resource oder fehlender Scope; widerrufenes/abgelaufenes Token; gültiges OAuth ohne learningSessionId sowie gültige Session ohne OAuth; unbekannte, manipulierte, widerrufene oder abgelaufene Session; direkter Zugriff auf Port 8787; im enforce-Modus externe /mcp-Aufrufe ohne gültiges OpenAI-Clientzertifikat, mit falscher Kette/SAN/EKU oder gefälschten Forwarding-/Klassifikationsheadern. Positiv wird der vollständige Ablauf über die konfigurierte App geprüft (der öffentliche positive mTLS-Nachweis im enforce-Modus ist ausschließlich über den echten gehosteten ChatGPT-Connector möglich).

Restannahmen: Nicht abgedeckt sind Kompromittierungen des SkillPilot-Hosts, Reverse Proxys oder der ChatGPT-Appkonfiguration, Verlust von SkillPilot-ID, aktivem Session-Link oder Client-Secret sowie vorsätzliche Weitergabe von Access-Token plus Session — begrenzt durch Secret-Rotation, kurze Tokenlaufzeiten, feste 24h-Sessions, Widerruf, minimale Scopes und redigierte Logs.

Normative OpenAI-Referenzen: Client identification · Client registration & authentication · Resource/Audience parameter · Mutual TLS (mTLS).