Tokenanforderung (Token request)

Was ist eine Tokenanforderung (Token request)?

In OAuth 2.0 und OpenID Connect (OIDC) ist eine Tokenanforderung (token request) eine Anforderung an den Autorisierungsserver (Authorization server) (oder OpenID Provider (OP) in OIDC), um Anmeldeinformationen (z. B. Autorisierungscode, Aktualisierungs-Token) gegen einen Satz von Tokens auszutauschen. Der Tokensatz umfasst typischerweise einen oder mehrere der folgenden:

• Zugriffstoken (Access token) : Ein Token, das den Zugriff auf geschützte Ressourcen gewährt.
• ID-Token : Ein Token, das Benutzerinformationen enthält (OIDC-spezifisch).
• Aktualisierungs-Token (Refresh token) : Ein Token, das verwendet werden kann, um ohne Benutzereingriff ein neues Zugriffstoken zu erhalten.

Abhängig vom verwendeten Grant-Typ kann die Anforderung unterschiedliche Parameter enthalten und verschiedene Tokens zurückgeben.

Beispielsweise fordert der Client-Credentials-Flow , dass der Client direkt mit den Client-Anmeldeinformationen ein Zugriffstoken (Access token) anfordert. Hier ist ein nicht normatives Beispiel der Tokenanforderung:

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
  &client_id=client-id
  &client_secret=client-secret
  &scope=read

Wenn die Anforderung erfolgreich ist, antwortet der Autorisierungsserver mit einem Zugriffstoken:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGci...zHg",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read"
}

Wie funktioniert eine Tokenanforderung (token request)?

Wie das obige Beispiel zeigt, ist die Tokenanforderung (token request) selbst unkompliziert. Der Client sendet eine HTTP-Anfrage an den Token-Endpunkt des Autorisierungsservers mit den erforderlichen Parametern. Der Autorisierungsserver validiert die Anforderung, verarbeitet sie und gibt die Tokens in der Antwort zurück.

Je nach verwendetem spezifischen Grant-Typ (Flow) kann die Tokenanforderung jedoch mehr Vorbereitung erfordern.

Autorisierungscode-Flow (Authorization code flow)

Im Autorisierungscode-Ablauf (Authorization code flow) erhält der Client zunächst einen Autorisierungscode (authorization code), indem er eine Autorisierungsanfrage (Authorization request) (oder Authentifizierungsanforderung (Authentication request) in OIDC) mit dem Autorisierungsserver initiiert. Sobald der Benutzer die Erlaubnis erteilt, tauscht der Client den Autorisierungscode (authorization code) über die Tokenanforderung gegen ein Zugriffstoken und optional ein Aktualisierungs-Token aus.

Hier ist ein vereinfachtes Sequenzdiagramm des Autorisierungscode-Flows:

Client-Anmeldeinformationen-Flow (Client credentials flow)

Wie das Beispiel im ersten Abschnitt zeigt, ist der Client-Credentials-Flow viel einfacher. Der Client fordert direkt mit seinen Client-Anmeldeinformationen ein Zugriffstoken (access token) an. Der Autorisierungsserver validiert die Client-Anmeldeinformationen und stellt ein Zugriffstoken aus, wenn erfolgreich.

Hier ist ein nicht normatives Sequenzdiagramm des Client-Anmeldeinformationen-Flows:

Aktualisierungs-Token (Refresh token)

Bei einigen Grant-Typen kann der Client auch Offline-Zugang (Offline access) anfordern, indem er den Geltungsbereich (scope) offline_access in die Autorisierungsanfrage aufnimmt. Wird dies gewährt, stellt der Autorisierungsserver ein Aktualisierungs-Token zusammen mit dem Zugriffstoken aus. Der Client kann das Aktualisierungs-Token verwenden, um über die Tokenanforderung ein neues Zugriffstoken zu erhalten, ohne dass eine Benutzerinteraktion erforderlich ist.

Hier ist ein nicht normatives Beispiel für die Verwendung eines Aktualisierungs-Tokens, um ein neues Zugriffstoken zu erhalten:

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
  &refresh_token=refresh-token
  &client_id=client-id
  &client_secret=client-secret

---

Andere Grant-Typen können auch Tokenanforderungen beinhalten, aber das Grundprinzip bleibt dasselbe.

Wichtige Parameter in einer Tokenanforderung (token request)

Hier sind einige wichtige Parameter, die häufig in einer Tokenanforderung (token request) verwendet werden:

• grant_type: Der Typ des angeforderten Grants. Häufige Werte sind authorization_code, client_credentials, refresh_token usw.
• client_id: Die vom Autorisierungsserver ausgegebene Client-Kennung.
• client_secret: Das vom Autorisierungsserver ausgegebene Client-Geheimnis (für vertrauliche Clients).
• code: Der vom Autorisierungsserver erhaltene Autorisierungscode (für den Autorisierungscode-Flow).
• refresh_token: Das vom Autorisierungsserver erhaltene Aktualisierungs-Token (zur Aktualisierung von Zugriffstokens).
• scope: Die angeforderten Geltungsbereiche (Berechtigungen) für das Zugriffstoken.
• redirect_uri: Die URI, an die der Autorisierungsserver die Antwort sendet (für den Autorisierungscode-Flow).
• code_verifier: Der im Proof Key for Code Exchange (PKCE) -Erweiterung verwendete Code-Verifizierer (für den Autorisierungscode-Flow).

Die tatsächlichen Parameter und ihre Werte hängen vom Grant-Typ und den spezifischen Anforderungen der Anwendung ab. Bevor du eine Tokenanforderung machst, solltest du die vollständige Liste der Parameter für den spezifischen Grant-Typ, den du verwendest, überprüfen.

Siehe auch

• OAuth 2.0
• OpenID Connect (OIDC)
• Autorisierungsanfrage (Authorization request)
• Authentifizierungsanforderung (Authentication request)