Die Verbindung eines Clients mit einer Server-URL gewährt keinen Zugriff auf geschützte Kontodaten. OAuth ermöglicht dem Client, delegierten Zugriff über einen Autorisierungsserver anzufordern – den Dienst, der das Token ausstellt.
Die MCP-Autorisierungsspezifikation definiert diesen Ablauf für HTTP-Transporte. Autorisierung ist für MCP-Implementierungen optional. Lokale stdio-Server verwenden eine separate Credential-Konfiguration.
Wie findet der Client heraus, wo er sich anmelden soll?
Der Client liest die Protected-Resource-Metadaten des MCP-Servers, um dessen Autorisierungsserver zu ermitteln.
Gemäß den Discovery-Regeln kann ein Server diese Metadaten-URL in einem WWW-Authenticate-Header einer 401-Antwort bereitstellen. Clients unterstützen die Erkennung auch über Well-Known-Metadatenpfade.
Das authorization_servers-Feld der Metadaten gibt die verfügbaren Autorisierungsserver an. Der Client ruft die Metadaten des ausgewählten Servers ab, um dessen Endpunkte und unterstützte Fähigkeiten zu ermitteln.
Wie identifiziert sich der Client?
Der Client erhält eine Client-ID über einen vom Autorisierungsserver unterstützten Registrierungsmechanismus.
Die MCP-Registrierungsregeln bevorzugen vorhandene, vorab registrierte Client-Informationen, sofern verfügbar. Andernfalls können Clients Client ID Metadata Documents verwenden, wenn der Server Unterstützung dafür signalisiert.
Ein Client ID Metadata Document ist ein JSON-Dokument an einer HTTPS-URL, das den Client beschreibt. Die URL dient als seine Client-ID.
Diese Regeln stufen die dynamische Client-Registrierung als veraltet ein. Dabei kann ein Client eine ID über einen Registrierungsendpunkt anfordern. Die Spezifikation behält den Mechanismus für die Kompatibilität mit Autorisierungsservern bei, die keine Metadaten-Dokumente unterstützen.
Wie erhält der Client das Token?
Der Client tauscht einen Autorisierungscode gegen ein Access Token ein, nachdem der Autorisierungsserver die Genehmigung erteilt hat.
Die Schutzregeln für Autorisierungscodes erfordern PKCE, das den Austausch an den Client bindet, der ihn initiiert hat. Der Client erzeugt einen geheimen Verifier und sendet eine daraus abgeleitete Challenge mit seiner Autorisierungsanfrage. Beim Einlösen des Codes liefert er den Verifier mit und verhindert so, dass ein abgefangener Code von einem anderen Aufrufer verwendet werden kann.
Was steuern Scopes und die Zielressource?
Scopes beschreiben die angeforderten Berechtigungen. Die Zielressource identifiziert den Server, für den der Client ein Token anfordert.
Die Scope-Auswahlregeln weisen Clients an, den scope-Wert der Challenge zu verwenden, wenn dieser bereitgestellt wird. Ein Client sollte nur den Zugriff anfordern, den seine Operation benötigt.
Der Client fügt den resource-Parameter in Autorisierungs- und Token-Anfragen ein. Er sendet das resultierende Token im Authorization-Header bei geschützten HTTP-Anfragen. Der empfangende Server prüft, ob das Token für ihn ausgestellt wurde.
Die Berechtigung, ein Tool aufzurufen, bedeutet nicht, dass ein bestimmter Aufruf zur Aufgabe des Benutzers passt. Der Host entscheidet weiterhin, ob er mit der vorgeschlagenen Aktion fortfährt.
Wie autorisiere ich einen Client für Bird?
Sie fügen die gehostete MCP-URL von Bird einem kompatiblen Client hinzu und schließen dessen Browser-Anmeldung ab.
Der dokumentierte Handshake von Bird verwendet dynamische Client-Registrierung. Das beschreibt den Verbindungsablauf von Bird getrennt vom in der Spezifikation bevorzugten Metadaten-Dokument-Mechanismus.
Wählen Sie auf dem Einwilligungsbildschirm die Workspace- oder Organisationsberechtigungen aus, die Sie delegieren möchten. Die Genehmigung ist begrenzt durch das, was der Client anfordert, was Sie freigeben und welche Rechte Sie selbst besitzen.
Der angezeigte Name des Clients ist selbst deklariert. Stellen Sie daher sicher, dass er mit dem von Ihnen gestarteten Client übereinstimmt. Sie können seine Genehmigung unter Connected apps in Ihrem Profil widerrufen.
Ein Tool kann weiterhin aufgelistet sein, auch wenn Ihre Genehmigung keine Berechtigung zu seinem Aufruf umfasst. Ein erfolgreicher whoami-Aufruf bestätigt die angemeldete Identität. Die angeforderte Operation benötigt weiterhin eigene Berechtigungen.
Bei einem lokalen bird mcp-Prozess verwendet der Server den gespeicherten Login des CLI. Die MCP-Einrichtungsanleitung beschreibt diesen separaten Weg.