2.1. Request (Anfrage)

2.1. Request (Anfrage)

Der Client sendet die Parameter der Autorisierungsanfrage direkt an den PAR-Endpunkt. Ein typischer Satz kann client_id, response_type, redirect_uri, scope, state, code_challenge und code_challenge_method wie unten enthalten. Die gepushte Autorisierungsanfrage kann jedoch aus allen am Autorisierungsendpunkt zulässigen Parametern bestehen, einschließlich der in [RFC6749] und aller anwendbaren Erweiterungen. Ausnahme ist der Autorisierungsanfrageparameter request_uri, der NICHT angegeben werden DARF.

Die Anfrage enthält je nach Client zusätzliche Parameter für die Client-Authentifizierung (z. B. client_secret oder client_assertion und client_assertion_type). Diese sind für den Token-Endpunkt definiert, gelten aber nur für die Client-Authentifizierung. In einer gepushten Autorisierungsanfrage dienen sie ausschließlich der Client-Authentifizierung, nicht der Autorisierungsanfrage selbst. Token-Endpunktparameter ohne Bezug zur Client-Authentifizierung sind für gepushte Autorisierungsanfragen nicht definiert. client_id hat dieselbe Semantik wie bei Autorisierungs- und Token-Anfragen und ist dort wie hier erforderlich.

Der Client bildet den Nachrichtenkörper der HTTP-POST-Anfrage im Format x-www-form-urlencoded mit UTF-8 gemäß Anhang B von [RFC6749]. Gegebenenfalls fügt er Authentifizierungsdaten gemäß denselben Regeln wie beim Token-Endpunkt in Header oder Körper ein.

Beispiel (Zeilenumbrüche im Körper nur zur Darstellung):

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information
&client_assertion_type=
 urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
 OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
 TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
 f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
 dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W
 yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE
 RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6
 GQ

Der Autorisierungsserver MUSS die Anfrage wie folgt verarbeiten:

1. Client wie am Token-Endpunkt authentisieren (Abschnitt 2.3 von [RFC6749]).

2. Die Anfrage ablehnen, wenn der Parameter request_uri gesetzt ist.

3. Die gepushte Anfrage wie eine normale Autorisierungsanfrage validieren (z. B. Redirect-URI und Berechtigung für den angeforderten scope). Der Server KANN Validierungsschritte auslassen, die beim Push nicht möglich sind; diese MÜSSEN dann am Autorisierungsendpunkt nachgeholt werden.

Der Autorisierungsserver KANN Clients mit Authentifizierungsdaten erlauben, bei jeder gepushten Anfrage eigene Redirect-URIs pro Autorisierungsanfrage zu setzen (Abschnitt 2.4), da im Gegensatz zu [RFC6749] Client-Authentifizierung und Validierung vor der eigentlichen Autorisierungsanfrage möglich sind.