2.1. Authorization Request (Autorisierungsanfrage)

2.1. Authorization Request (Autorisierungsanfrage)

Wird der Parameter resource in einer Autorisierungsanfrage an den Autorisierungsendpunkt verwendet, gibt er die Identität der geschützten Ressource(n) an, auf die Zugriff angefordert wird. Wird ein Zugriffstoken direkt vom Autorisierungsendpunkt über den Implicit Flow (Abschnitt 4.2 von OAuth 2.0 [RFC6749]) zurückgegeben, gilt die angeforderte Ressource für dieses Zugriffstoken. Beim Code-Flow (Abschnitt 4.1 von OAuth 2.0 [RFC6749]), bei dem vom Autorisierungsendpunkt eine Zwischendarstellung der Autorisierungsgewährung (der Autorisierungscode) zurückgegeben wird, gilt die angeforderte Ressource für die vollständige Autorisierungsgewährung.

Bei einer als JSON Web Token (JWT) gesendeten Autorisierungsanfrage, etwa bei Verwendung des JWT Secured Authorization Request [JWT-SAR], wird ein einzelner resource-Parameterwert als JSON-String dargestellt, mehrere Werte als Array von Strings.

Lässt der Client den Parameter resource bei der Autorisierungsanfrage weg, KANN der Autorisierungsserver die Anfrage ohne spezifische Ressource oder mit einem vordefinierten Standard-Ressourcenwert bearbeiten. Alternativ KANN der Autorisierungsserver von Clients verlangen, die Ressource(n) anzugeben, auf die sie zugreifen wollen, und Anfragen, die den Parameter weglassen, mit einem invalid_target-Fehler ablehnen. Der Autorisierungsserver kann diese Daten nutzen, um den Nutzer über die Ressourcen zu informieren, auf die der Client in seinem Namen zugreifen wird, Richtlinien anzuwenden (z. B. die Anfrage wegen unbekannter Ressourcen ablehnen) und die Menge der Ressourcen zu bestimmen, die in späteren Zugriffstoken-Anfragen verwendet werden können.

Kann der Autorisierungsserver die bereitgestellte(n) Wert(e) nicht parsen oder hält er die Ressource(n) nicht für akzeptabel, SOLLTE er die Anfrage mit einer Fehlerantwort ablehnen, die den Fehlercode invalid_target als Wert des Parameters error verwendet, und KANN zusätzliche Informationen zu den Fehlergründen über error_description bereitstellen.

Abbildung 1 zeigt ein Beispiel einer Autorisierungsanfrage, in der der Client dem Autorisierungsserver mitteilt, dass er ein Zugriffstoken für die Nutzung unter https://api.example.com/app/ wünscht (zusätzliche Zeilenumbrüche und Einrückung nur zu Anzeigezwecken).

GET /as/authorization.oauth2?response_type=token
   &client_id=example-client
   &state=XzZaJlcwYew1u0QBrRv_Gw
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com

Abbildung 1: Autorisierungsanfrage im Implicit Flow

Abbildung 2 zeigt unten ein Beispiel einer Autorisierungsanfrage mit dem Antworttyp code, bei der der Client Zugriff auf Kontakte und Kalenderdaten des Ressourceninhabers unter https://cal.example.com/ und https://contacts.example.com/ anfordert (zusätzliche Zeilenumbrüche und Einrückung nur zu Anzeigezwecken).

GET /as/authorization.oauth2?response_type=code
   &client_id=s6BhdRkqt3
   &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &scope=calendar%20contacts
   &resource=https%3A%2F%2Fcal.example.com%2F
   &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com

Abbildung 2: Autorisierungsanfrage im Code-Flow