Wie funktioniert die MCP-Authentifizierung? Prüfung der OAuth-Kette

Für einen geschützten Remote MCP Server ist Authentifizierung kein einziger Token Check. Es handelt sich um eine Berechtigungskette: Der Client erhält eine Herausforderung, entdeckt Metadaten für die exakte geschützte Ressource, entdeckt und validiert einen Berechtigungsserver, erhält eine Clientidentität, führt einen Berechtigungscode Flow mit PKCE und einem Ressourcenindikator aus, erhält die erforderlichen Bereiche und beweist, dass das resultierende Token am beabsichtigten MCP Endpunkt arbeitet. Diese Antwort hat eine wichtige Grenze. Die aktuelle Spezifikation der Zulassung von MCPs macht die Berechtigung optional und wendet ihren OAuth Pfad auf HTTP basierte Transporte an. Ein lokaler STDIO Server sollte stattdessen Anmeldeinformationen über seine Host Umgebung oder einen anderen lokalen Mechanismus erhalten. Der Start eines Browserflusses für jede MCP Verbindung ist daher keine angemessene Standardfunktion. Die operative Frage ist nicht do I have a token? Es ist Welche Quittungen zeigen, dass jede Bindung in dieser bestimmten Autorisierungskette zustimmt? Eine tokenförmige Zeichenfolge kann mit der falschen Ressource, einem unzuverlässigen Emittenten, fehlenden Umfang oder einer geschützten Anfrage koexistieren, die immer noch 401 zurückgibt. Beginnen Sie mit dem Transport und der ersten Herausforderung Der offizielle Tutorial zur Genehmigung von MCP erklärt den Remote HTTP Flow in Stufen. in gekundener Form: 1. Der Kunde sendet eine MCP Anfrage ohne Token. 2. Der geschützte MCP Server gibt 401 Unauthorized mit einer Herausforderung mit Bearer WWW Authenticate zurück. 3. Die Herausforderung weist auf Metadaten aus geschützten Ressourcen durch resource metadata hin. 4. Diese Metadaten identifizieren die geschützte Ressource und einen oder mehrere Berechtigungsserver. 5. Der Client holt die Metadaten des Autorisierungsservers und validiert den Emittenten und die Endpunkte. 6. Der Client erhält eine Client ID über einen Mechanismus, den der Autorisierungsserver unterstützt, und führt dann den Autorisierungs Code Flow mit PKCE und dem MCP Ressource Identifier aus. 7. Der Client sendet das entstehende Zugriffs Token an den MCP Server und beobachtet die geschützte Anfrage. Der erste 401 ist kein Versagen bei der Unterdrückung. Es ist eine Entdeckungsrechnung. Eine nützliche Aufzeichnung speichert den HTTP Status, die Authentifizierungsregelung, die Metadaten URL, die Beobachtungszeit und die ausgewählte MCP Ressource. Znot hält den Authorization Header, Cookies, Autorisierungscode, Verifier, Client Geheimnis oder Zugriffs Token. RFC 9728 definiert die Metadaten der geschützten Ressourcen und das bekannte Entdeckungsmuster. Sein Sicherheitswert hängt von der Autorität ab: Metadaten für https://mcp.example/mcp müssen diese Ressource beschreiben und nicht einen ähnlichen Host oder eine URL, die von einem unabhängigen Dienst bereitgestellt wird. Eine URL nach einer beliebigen Berechtigung aus einem Fehlerkörper ist nicht gleichwertig. Der Autorisierungsserver ist eine separate Rolle. Ein geschützter MCP Server fungiert als OAuth Ressource Server; der MCP Client fungiert als OAuth Client; der Berechtigungsserver interagiert bei Bedarf mit dem Benutzer und gibt Zugriffströme aus. Durch die Verwechslung dieser Rollen erscheint ein häufiger Fehler bei der Fehlerbehebung plausibel: Sie drehen ein Ressourcen Server Token, bevor sie überprüfen, ob der Client den richtigen Emittenten entdeckt hat. Binden Sie die Ressource, Emittent, Client und Code Flow Zwei URLs verdienen einen genauen Vergleich. Die erste ist die geschützte Ressource. RFC 8707 definiert den resource Anforderungsparameter, so dass ein Berechtigungsserver den beabsichtigten Empfänger eines Tokens kennt. Der aktuelle MCP Entwurf erfordert den Ressourcenparameter sowohl bei Genehmigungs als auch bei Token Anfragen. Ein für eine andere API ausgestelltes Zugriffs Token ist für den ausgewählten MCP Server nicht fast gültig. Der zweite ist der Autorisierungsserver Emittent. Vor dem Öffnen des Browsers erfasst ein Client den Emittenten aus validierten Metadaten des Autorisierungsservers. Wenn eine Berechtigungsreaktion iss beinhaltet, beschreibt der aktuelle MCP Entwurf einen Vergleich mit diesem aufgezeichneten Wert, bevor der Client den Code an einen Token Endpunkt sendet. Eine Ausstellerunvereinbarkeit ist eine Stoppbedingung, nicht ein Grund, den gleichen Code gegen beide Endpunkte zu versuchen. Die Kundenregistrierung ist auch eine explizite Schicht. Ein Client kann ein Client ID Metadatendokument, eine vorgegebene Client ID oder einen unterstützten Dynamischregistrierungsweg verwenden. Der aktuelle Entwurf behandelt die dynamische Kundenregistrierung als Kompatibilitätsmechanismus und nicht als universelle Annahme. Wenn es keinen unterstützten Registrierungsmechanismus gibt, ist das korrekte Urteil registration blocked ; die Erfindung eines Umleitungs URI oder die Wiederverwendung eines anderen Produkts Client ID würde den tatsächlichen Interoperabilitätsfehler verbergen. Die PKCE verbindet die Genehmigungsanfrage an den späteren Code Austausch. Die Prüfung erfasst nur, ob der Fluss einen gebundenen Prüfer behielt, nie den Prüfer selbst. Eine fehlende Bindung wird unsafe flow , auch wenn ein Browser einen Code zurückgab. Hier ist die inhaltsfreie Form, die für ein gesundes Gerät verwendet wird: Die Namen der Bereiche sind Konfigurationsnachweise, nicht geheime Werte. In einem sensiblen Einsatz können sie noch Fähigkeiten offenbaren, so dass sie nur das behalten, was die Gesundheitsentscheidung benötigt, und die gleichen Zugriffskontrollen wie andere operative Metadaten anwenden. Diagnose der ersten fehlgeschlagenen Schicht Eine flache Checkliste führt zu widersprüchlichen Handlungen. Wenn Metadaten aus geschützten Ressourcen nicht verfügbar sind, ist der Emittentenvergleich nicht zuverlässig. Wenn der Ressourcenidentifikator falsch ist, kann eine Erweiterung des Umfangs nicht repariert werden. Der Klassifizierer hat daher Vorrang und hält bei der ersten fehlgeschlagenen Schicht: Urteil Beweise, die die Kette gestoppt haben Verbotene nächste Aktion not applicable Lokale STDIO Transporte Verwenden Sie den lokalen Anmelde Mechanismus runtime invalid challenge Fehlende oder nicht HTTPS resource metadata Reparatur der 401 Herausforderung metadata unavailable Metadaten aus geschützten Ressourcen wurden nicht zur 200 zurückgegeben Wiederherstellen von Metadaten; raten Sie nicht den Emittenten resource mismatch Metadaten oder Token zielen auf eine andere Ressource ab Korrigieren Sie die Ressourcenidentität oder beantragen Sie ein ressourcengebundenes Token issuer mismatch Entdeckte oder Rückruf Emittent nicht einverstanden Ablehnen Sie den Strom und untersuchen Sie die Metadatenbehörde registration blocked Keine unterstützte Kundenidentität Konfiguration eines unterstützten Registrierungsmechanismus unsafe flow Der Autorisierungscode Flow fehlt einer PKCE Bindung Neustart mit PKCE step up required Die derzeitige Operation benötigt einen nicht zugelassenen Umfang. Erfordern Sie nur den angefochtenen fehlenden Anwendungsbereich token rejected Die Verpflichtungen stimmen zu, aber der geschützte Antrag ist immer noch nicht erfolgreich. Klassifizieren Sie die neue Herausforderung vor der Rotation authorized ready Alle Genehmigungsbestätigungen stimmen zu und der Antrag ist erfolgreich. Weiterführung der MCP Initialisierung und der Ergebnisprüfung Das angebotene Gerät kann ohne Netzwerkzugang wiedergegeben werden: Seine datierte Laufzeit führte zu zehn Fällen, zehn Urteilen der ersten Schicht, einem authorized ready und secretFieldsStored: 0 . Dieses Ergebnis ist absichtlich strenger als 9 Fehler und ein Erfolg. Es beweist, dass die Entscheidungsregel bedeutende Unterschiede zwischen einem lokalen Transport, fehlgeschlagener Entdeckung, widersprüchlicher Identität, nicht unterstützter Registrierung, unsicheren Code Flow, fehlender Umfang und abgelehntem Token bewahrt. Die Regel der ersten fehlgeschlagenen Schicht beschränkt auch erneute Versuche. metadata unavailable kann einen erneuten Versuch mit begrenzten Metadaten rechtfertigen. issuer mismatch sollte nicht. step up required kann einen neuen Einwilligungsfluss für den angefochtenen Anwendungsbereich rechtfertigen. token rejected erfordert das Lesen der neuen Herausforderung, weil Verfallsdauer, Widerruf, Publikum und Umfang nicht eine Reparatur teilen. Halten Sie die Reichweite Steigerung getrennt von Token Fehlern Der derzeitige Entwurf des MCP empfiehlt, dass ein Server den erforderlichen Umfang in seine WWW Authenticate Herausforderung einbezieht. Der für die aktuelle Operation angefochtene Umfang ist für diese Operation autoritativ; er muss nicht gleich dem gesamten scopes supported Satz der Ressourcenmetadaten sein. Dies ändert die Entscheidung des Betreibers. Nehmen wir an, dass eine Lesung mit files:read erfolgreich ist, dann gibt ein Schreiben 403 und Herausforderungen für files:write zurück. Das ist kein Beweis dafür, dass der Token Shop korrupt ist. Es ist ein step up required Zustand. Der Kunde sollte die fehlende Genehmigung mit menschlicher Sicht beantragen und die für andere Operationen noch benötigten Genehmigungen behalten. Im Gegensatz dazu ist ein geschützter Antrag, der 401 nach Einigung der Ressourcen , Emittenten , Registrierungs , PKCE und Umfangsrechnungen zurückgibt, token rejected . Der nächste Schritt ist, die neue Herausforderung zu klassifizieren. Wiederholt das gleiche Zeichen darzustellen, ist Aktivität, nicht Fortschritt. Das Rotatieren aller Anmeldeinformationen kann auch nützliche Beweise zerstören und gesunde Kunden unterbrechen. Das Urteil von authorized ready bleibt eng. Der Remote MCP Server hat die Autorisierungskette für diese Anfrage akzeptiert. Es steht nicht: Die Initialisierung der MCP und die Verhandlung über die Fähigkeiten erfolgreich; das ausgewählte Instrument noch existiert oder sein Schema unverändert ist; ein Geräteaufruf, das die beabsichtigte äußere Wirkung erzeugte; eine Nebenwirkung ist nach einer Pause sicher erneut zu versuchen; der Nutzers Lieferwert existiert; Der Autorisierungsserver, der Client und die Ressource sind weltweit vertrauenswürdig. Das sind spätere Gesundheits und Sicherheitsentscheidungen. Eine erfolgreiche geschützte Anfrage sollte den Betrieb in die MCP Lebenszykluskontrolle und dann in die Werkzeug Effekt und Ergebnisverifizierung nicht direkt in Agent healthy übertragen. Verwenden Sie die Quittung ohne die Bescheinigungen zu sammeln Für Produktionsvorgänge speichern Sie Hashes oder stabile IDs für den ausgewählten Client und die Ressource nur, wenn sie zur Korrelation von Ereignissen erforderlich sind. Zeitstempel und Spezifikationsversion aufzeichnen, da sich Metadaten und Protokollregeln weiterentwickeln. Bewahren Sie die Roh Token, Code, Verifier, Geheimnis, Cookie, Anforderung, Werkzeugargumente und Werkzeugergebnisse aus dem Gesundheitsregister. Das Artefakt ist ein Klassifikator, nicht eine Live Konformitätssuite. Es vertraut den ihm zur Verfügung gestellten Beobachtungen. Eine echte Implementierung muss zusätzlich TLS, Metadaten Origin, Umleitung von URIs, Emittentenverhalten, Token Signaturen oder Introspektion, Publikum, Ablauf und Bereitstellungsrichtlinien validieren. Der Entwurf des MCP wurde am 30. Juli 2026 überprüft. Stecken Sie die Spezifikation an, die Sie implementieren, und starten Sie das Gerät erneut, wenn sich der Vertrag ändert. Das beabsichtigte Produktgebiet von Sidewisp umfasst die Verfügbarkeit von Werkzeugen, verfallene Anmeldeinformationen, Verlust von Genehmigungen, nützliche Fortschritte und Ergebnisseprüfung. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Die Produktionsüberwachungsadapter und der Wiederherstellungs Executor werden im Allgemeinen nicht ausgeliefert, so dass dieser Artikel eine unabhängige Betriebsregel enthält, anstatt zu behaupten, dass Sidewisp diese MCP Zulassungsprüfung bereits durchführt. Die praktische Antwort auf wie funktioniert die MCP Authentifizierung? ist daher eine Kette von Zulassungsergebnissen, nicht ein Screenshot eines Träger Token. Die erste Widersprüche gilt als Diagnose, eine begrenzte Reparatur angewendet und der Erfolg der Berechtigung getrennt von dem Erfolg des Werkzeugs und dem endgültigen Ergebnis des Benutzers.