Zum Inhalt springen
Sursa Developers

POST/oauth/token

OAuth-2.0-Token ausstellen

oauth_token

Der Token-Endpunkt von OAuth 2.0 (RFC 6749, Abschnitt 3.2). grant_type: authorization_code tauscht einen Einmalcode gegen ein Token-Paar und erfordert code_verifier (PKCE S256); refresh_token stellt für ein Refresh-Token ein neues Paar aus und macht das vorherige Refresh-Token ungültig (Rotation), und die erneute Verwendung eines ungültig gemachten Tokens widerruft die gesamte Kette; client_credentials stellt ein Token im Namen der Organisation aus, nur für eine App vom Typ confidential und ohne Refresh-Token. Ein Client vom Typ confidential authentifiziert sich mit dem Header Authorization: Basic oder mit den Feldern client_id und client_secret; ein öffentlicher Client sendet nur client_id. Ein Zugriffstoken ist 1 Stunde gültig, ein Refresh-Token 90 Tage. Antworten und Fehler folgen RFC 6749, Abschnitt 5, mit Cache-Control: no-store. Hinzugefügt in 1.62.0.

Authentifizierung

Keine Anmeldedaten erforderlich.

Anfragetext

application/x-www-form-urlencoded

Objekt: OAuthTokenRequest

  • grant_typestringerforderlich

    Zulässige Werte: authorization_coderefresh_tokenclient_credentials

  • codestring

    Autorisierungscode (authorization_code).

  • redirect_uristring

    Dieselbe Weiterleitungs-URI wie in der Autorisierungsanfrage (authorization_code).

  • code_verifierstring

    Der ursprüngliche PKCE-Wert, 43 bis 128 Zeichen (authorization_code).

  • refresh_tokenstring

    Refresh-Token (refresh_token).

  • scopestring

    Durch Leerzeichen getrennte Scopes, nur zur Einschränkung (refresh_token, client_credentials).

  • client_idstring

    App-ID, wenn das Secret nicht im Header Authorization: Basic übergeben wird.

  • client_secretstring

    Client-Secret einer App vom Typ confidential, wenn es nicht im Header Authorization: Basic übergeben wird.

Antworten

200Die Tokens wurden ausgestellt.

Antwort-Header

  • RateLimit-Policy

    Geltende Limits im Format des IETF-Entwurfs draft-ietf-httpapi-ratelimit-headers: durch Kommas getrennte Einträge "<name>";q=<quota>;w=<window in seconds>. key ist die Anfragerate des API-Schlüssels (das Kontingent ist der Burst, das Fenster die Zeit bis zum vollständigen Auffüllen; für eine Sitzung heißt der Eintrag user, ohne Anmeldedaten ip); minute, day und month sind die Kontingente der Organisation für die Kalenderminute, den Kalendertag und den Kalendermonat in UTC.

  • RateLimit

    Was von jedem Limit in RateLimit-Policy übrig ist: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Limit des strengsten Eintrags in RateLimit-Policy (des Eintrags mit den wenigsten verbleibenden Anfragen).

  • X-RateLimit-Remaining

    Verbleibende Anfragen unter dem strengsten Limit.

  • X-RateLimit-Reset

    Sekunden bis zum Zurücksetzen des strengsten Limits.

application/json

Objekt: OAuthTokenResponse

  • access_tokenstringerforderlich

    Zugriffstoken (kbat_…) für den Header Authorization: Bearer.

  • token_typestringerforderlich

    Zulässige Werte: Bearer

  • expires_inintegererforderlich

    Lebensdauer des Zugriffstokens in Sekunden.

  • refresh_tokenstring

    Refresh-Token (kbrt_…); fehlt bei Client Credentials.

  • scopestringerforderlich

    Durch Leerzeichen getrennte Scopes des Tokens.

400Fehler gemäß RFC 6749, Abschnitt 5.2.

Antwort-Header

  • RateLimit-Policy

    Geltende Limits im Format des IETF-Entwurfs draft-ietf-httpapi-ratelimit-headers: durch Kommas getrennte Einträge "<name>";q=<quota>;w=<window in seconds>. key ist die Anfragerate des API-Schlüssels (das Kontingent ist der Burst, das Fenster die Zeit bis zum vollständigen Auffüllen; für eine Sitzung heißt der Eintrag user, ohne Anmeldedaten ip); minute, day und month sind die Kontingente der Organisation für die Kalenderminute, den Kalendertag und den Kalendermonat in UTC.

  • RateLimit

    Was von jedem Limit in RateLimit-Policy übrig ist: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Limit des strengsten Eintrags in RateLimit-Policy (des Eintrags mit den wenigsten verbleibenden Anfragen).

  • X-RateLimit-Remaining

    Verbleibende Anfragen unter dem strengsten Limit.

  • X-RateLimit-Reset

    Sekunden bis zum Zurücksetzen des strengsten Limits.

application/json

Objekt: OAuthErrorResponse

401Ungültige Client-Anmeldedaten (`invalid_client`).

Antwort-Header

  • RateLimit-Policy

    Geltende Limits im Format des IETF-Entwurfs draft-ietf-httpapi-ratelimit-headers: durch Kommas getrennte Einträge "<name>";q=<quota>;w=<window in seconds>. key ist die Anfragerate des API-Schlüssels (das Kontingent ist der Burst, das Fenster die Zeit bis zum vollständigen Auffüllen; für eine Sitzung heißt der Eintrag user, ohne Anmeldedaten ip); minute, day und month sind die Kontingente der Organisation für die Kalenderminute, den Kalendertag und den Kalendermonat in UTC.

  • RateLimit

    Was von jedem Limit in RateLimit-Policy übrig ist: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Limit des strengsten Eintrags in RateLimit-Policy (des Eintrags mit den wenigsten verbleibenden Anfragen).

  • X-RateLimit-Remaining

    Verbleibende Anfragen unter dem strengsten Limit.

  • X-RateLimit-Reset

    Sekunden bis zum Zurücksetzen des strengsten Limits.

application/json

Objekt: OAuthErrorResponse

Sichere Wiederholungen

Senden Sie bei jedem POST und PATCH einen Header Idempotency-Key (zum Beispiel eine UUID). Eine Wiederholung mit demselben Schlüssel innerhalb von 24 Stunden gibt die gespeicherte Antwort zurück, statt die Anfrage erneut auszuführen.

Ratenlimits

Antworten enthalten die Header RateLimit und RateLimit-Policy sowie die älteren X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset. Eine Antwort 429 enthält Retry-After in Sekunden: Warten Sie und versuchen Sie es dann erneut.

← oauth · API-Referenz