Autorisierung in MCP 2026-07-28: Aussteller prüfen und Clientregistrierung anpassen

Worum es geht

Stand: 25. Oktober 2026. Die Änderungen an der Autorisierung in 2026-07-28 betreffen die Validierung des Ausstellers, die Registrierung und die Zuordnung von Zugangsdaten. Vor der Einführung die versionierte Autorisierungsspezifikation, die Registrierungsregeln und die Metadaten des Autorisierungsservers erneut prüfen. Client ID Metadata Documents (CIMD) werden hier nicht neu eingeführt: Bereits das Änderungsprotokoll zu 2025-11-25 empfiehlt sie. Die neue Revision kündigt Dynamic Client Registration (DCR) formell ab, behält es aber aus Kompatibilitätsgründen bei.

Der MCP-Server ist die geschützte Ressource, der MCP-Client erhält Zugriff, und der Autorisierungsserver stellt Tokens aus. Änderungen können deshalb unterschiedliche Dienste betreffen, selbst wenn sie alle vom selben Betreiber betrieben werden. Das OAuth-Rahmenwerk von MCP gilt für HTTP-Deployments; für stdio ist es nicht der vorgeschriebene Mechanismus für Zugangsdaten.

Warum es wichtig ist

Ein Autorisierungsablauf muss dem Aussteller zugeordnet bleiben, der zu Beginn ausgewählt wurde. Andernfalls können geänderte Endpunkte oder mehrdeutige Registrierungsdatensätze dazu führen, dass Zugangsdaten beim falschen Autorisierungsserver verwendet werden. CIMD bringt ausserdem Aufgaben beim Abruf von Dokumenten und bei der Validierung von Weiterleitungen mit sich; allein eine Clientkennung in URL-Form zu erkennen, begründet noch kein Vertrauen in die Anwendung.

So wird es angewendet

• Autorisierungsantworten vor dem Einlösen des Codes validieren. Clients speichern den Aussteller aus den validierten Servermetadaten zusammen mit dem PKCE-Verifier des Autorisierungsversuchs. Autorisierungsserver sollten iss zurückgeben und müssen in diesem Fall die Unterstützung dafür bekannt geben. Clients vergleichen jeden zurückgegebenen iss-Wert nach der Formulardekodierung exakt mit dem gespeicherten Wert, ohne URL-Normalisierung. Bei einer Abweichung wird die Antwort abgelehnt, auch wenn es sich um eine Fehlerantwort handelt. Wenn die Metadaten die Unterstützung des Ausstellerparameters ankündigen, iss aber fehlt, die Antwort ablehnen; wird die Unterstützung weder angekündigt noch der Parameter geliefert, erlaubt die Spezifikation die Fortsetzung.
• Registrierungszugangsdaten an den Aussteller binden. Zugangsdaten aus einer Vorabregistrierung oder DCR unter der Kennung des ausstellenden Servers dauerhaft speichern. Sie niemals bei einem anderen Aussteller wiederverwenden. Für den neuen Server eine Registrierung beschaffen; bei einer nicht passenden Vorabregistrierung einen Fehler anzeigen. Diese Regel macht eine selbst gehostete CIMD-Kennung nicht ausstellerspezifisch: Die Registrierungsspezifikation erlaubt ausdrücklich, diese URL-Kennung ohne erneute Registrierung bei anderen Ausstellern zu verwenden.
• Die Regeln zur Wahl des Registrierungsverfahrens befolgen. Eine verfügbare Vorabregistrierung bevorzugen, danach CIMD wählen, wenn es über client_id_metadata_document_supported angekündigt wird, und anschliessend unterstütztes DCR als Kompatibilitätslösung nutzen. Ein CIMD-Dokument verwendet HTTPS mit einem Pfad und enthält client_id, client_name und redirect_uris. Seine client_id muss der Dokument-URL entsprechen; das JSON und die angeforderte Weiterleitung anhand des Dokuments validieren.
• Den Metadatenabruf absichern. Beim Abruf von Clientdokumenten die dokumentierten Schutzmassnahmen gegen serverseitige Anfragenfälschung anwenden. Vertrauensrichtlinien für Domains in Betracht ziehen. CIMD allein kann Identitätsvortäuschung unter Verwendung von localhost-Weiterleitungen nicht verhindern; während der Autorisierung wie vorgeschrieben den Hostnamen des Weiterleitungsziels anzeigen.
• Bisheriges DCR weiterhin korrekt betreiben. Clients müssen einen passenden application_type angeben. Native Desktop-, CLI- und localhost-Anwendungen sollten native verwenden, entfernte Browseranwendungen sollten web verwenden. Registrierungsfehler untersuchen, statt Weiterleitungsprüfungen zu lockern, damit die Fehler verschwinden.
• Das bestehende Sicherheitsniveau erhalten. Die PKCE-Unterstützung in den Metadaten prüfen, gespeicherte Tokens schützen und validieren, dass eingehende Tokens für diese MCP-Ressource bestimmt sind. Aufrufe vorgelagerter APIs benötigen separat für diese Dienste ausgestellte Tokens. Die Migration der Registrierung erlaubt weder das Durchreichen von Tokens noch das Entfernen von Zustimmungsprüfungen.

Stolpersteine

DCR nicht als bereits entfernt darstellen und CIMD nicht als allgemein verpflichtend: Seine Unterstützung ist eine Empfehlung. Als vorgeschlagenen Abnahmetest in Staging Antworten mit korrektem, abweichendem und fehlendem Aussteller, einen Ausstellerwechsel sowie jedes beibehaltene Registrierungsverfahren durchspielen. Prüfen, dass abgelehnte Antworten nie zum Einlösen des Codes führen. Diese Prüfungen betreffen die Protokollkonformität; sie sind kein Sicherheitsaudit einer bestimmten Autorisierungsumgebung.