Skip to main content
POST
Rufen Sie kurzlebige MCP-Zugriffstokens mithilfe des S256-Autorisierungscodes eines öffentlichen Clients oder seines aktuellen Aktualisierungstokens ab.

​
Authentifizierung

Keine HTTP-Clientauthentifizierung. Senden Sie client_id im URL-kodierten Anfragetext. Jeder Authorization-Header sowie client_secret oder client_assertion werden abgelehnt.

​
Anfragetext

​
Anfragebeispiele

Beachten Sie die für diese Route dokumentierte Kodierung und Authentifizierung. Die Antwortstruktur und Idempotenzregeln der Aktions-API gelten nur für Aktionsaufrufe.

​
Antwort

Ein opakes Bearer-Zugriffstoken, seine verbleibende Gültigkeitsdauer in Sekunden, die gewährten Berechtigungen und ein Refresh-Token, wenn der Client refresh_token registriert hat. expires_in beträgt höchstens 900 und kann kurz vor Ablauf der Autorisierung kleiner sein.
HTTP 200

​
Antwortheader

​
Hinweise zur Operation

  • Erkannte skalare Parameter müssen genau einmal als nicht leere Zeichenfolgen ohne ASCII-Steuerzeichen oder DEL übergeben werden. Wiederholte Abfrage- oder Formularfelder werden als Arrays dekodiert und beim Lesen als Skalare abgelehnt.
  • Verwenden Sie URL-codierte Formulardaten, beispielsweise curl —data-urlencode für jedes Feld. Ein JSON-Token-Body wird mit invalid_request abgelehnt.
  • Die resource-Zielgruppe ist für beide Grant-Typen erforderlich und muss exakt mit der MCP-URL der Umgebung übereinstimmen, die den Code oder das Aktualisierungstoken ausgestellt hat.
  • Der Austausch eines Autorisierungscodes erfordert die ursprüngliche client_id, die exakte redirect_uri und den passenden S256 code_verifier. Codes laufen nach 2 Minuten ab und sind nur einmal verwendbar.
  • Der Token-Endpunkt lehnt jeden übergebenen Authorization-Header ab, einschließlich Basic und Bearer, sowie jedes client_secret- oder client_assertion-Feld im Anfragetext.
  • Zugriffstoken sind höchstens 15 Minuten gültig. Wenn refresh_token registriert ist, laufen die Verbindung und die Refresh-Token-Familie 30 Tage nach der Zustimmung des Benutzers ab; eine Rotation verlängert diese Frist nicht.
  • Ob refresh_token zurückgegeben wird, hängt von den registrierten Grant-Typen ab. Es hängt nicht davon ab, ob offline_access in der Autorisierungsanfrage enthalten ist. Der zurückgegebene scope ergänzt offline_access immer dann, wenn ein Refresh-Token zurückgegeben wird.
  • Senden Sie zur Erneuerung grant_type=refresh_token mit client_id, dem aktuellen refresh_token, resource und optional einem eingeschränkten scope. Ersetzen Sie das gespeicherte Refresh-Token atomar durch den neuen Wert.
  • Die Wiederverwendung eines verbrauchten Autorisierungscodes oder eines rotierten Refresh-Tokens widerruft die gesamte Verbindung einschließlich aller ihrer Zugriffstoken. Lösen Sie denselben Code oder dasselbe Refresh-Token nicht gleichzeitig mehrfach ein.
  • Erneuerungsanfragen fügen niemals Berechtigungen hinzu. Bei einem expliziten scope bleiben nur die angeforderten Produkt- und Identitätsberechtigungen erhalten; offline_access bewahrt ausgelassene Produktberechtigungen nicht.
  • Tokens sind an den gewährenden Nutzer, den Client, die Ressourcen-Audience, die aktuelle Teameigentümerschaft und den aktiven kostenpflichtigen Zugriff gebunden. Eine widerrufene Berechtigung oder geänderte Eigentümerschaft erfordert eine erneute Verbindung.
  • Das öffentliche Token-Limit beträgt 60 Anfragen pro Minute und Client-IP und gilt gemeinsam für alle Worker. URL-codierte Bodys sind auf 32 KiB begrenzt.
  • Bei OAuth-Fehlern werden error und error_description zurückgegeben. Fehler des Body-Parsers können bereits zuvor im Fehlerformat des Integrationsparsers zurückgegeben werden.
  • openid und email sind Identitätsberechtigungen, getrennt von Produktberechtigungen, und werden nur akzeptiert, wenn sie angekündigt werden. email erfordert openid. Bei der ersten Autorisierung verwendet eine Anfrage nur mit Identitäts-Scopes die auf dem Zustimmungsbildschirm angezeigten Standard-Produktberechtigungen.
  • Die von der dynamischen Registrierung zurückgegebene client_id oder die exakte öffentliche HTTPS-URL des Client-Metadatendokuments.
  • Wenn openid gewährt wurde, gibt der Austausch des Autorisierungscodes zusätzlich ein mit RS256 signiertes id_token zurück. Prüfen Sie Signatur, Aussteller, Zielgruppe, Ablaufzeit und gegebenenfalls nonce. Gewährte Identitäts-Scopes erscheinen in scope der Tokenantwort; Erneuerungsantworten geben kein neues id_token aus.
  • Wenn OpenID Connect nicht mehr verfügbar ist, behält eine Erneuerung ohne scope die Produktberechtigungen bei und entfernt Identitätsberechtigungen. Eine ausdrückliche Anfrage nicht verfügbarer Identitäts-Scopes gibt invalid_scope zurück.
  • Wenn das Konto gelöscht oder deaktiviert wurde, gibt der Token-Endpunkt invalid_grant mit HTTP 400 zurück.

​
Fehler