2.1. Request (Richiesta)
2.1. Request (Richiesta)
Il client invia direttamente all’endpoint PAR i parametri che compongono una richiesta di autorizzazione. Un insieme tipico può includere client_id, response_type, redirect_uri, scope, state, code_challenge e code_challenge_method come nell’esempio seguente. Tuttavia la richiesta di autorizzazione inviata (pushed) può essere composta da qualsiasi parametro utilizzabile all’endpoint di autorizzazione, inclusi quelli definiti in [RFC6749] e tutte le estensioni applicabili. Eccezione: il parametro request_uri della richiesta di autorizzazione NON DEVE essere fornito.
La richiesta include, a seconda del client, eventuali parametri aggiuntivi necessari all’autenticazione del client (ad es. client_secret o client_assertion e client_assertion_type). Questi sono definiti e registrati per l’endpoint del token ma riguardano solo l’autenticazione del client. Se presenti in una richiesta di autorizzazione inviata via PAR servono esclusivamente a tale scopo, non alla richiesta di autorizzazione stessa. Parametri dell’endpoint del token senza rapporto all’autenticazione del client non hanno significato definito per una richiesta PAR. client_id ha la stessa semantica per le richieste di autorizzazione e per quelle al token ed è obbligatorio anche nella richiesta PAR.
Il client costruisce il corpo della richiesta HTTP POST con parametri in formato x-www-form-urlencoded e codifica UTF-8, come nell’appendice B di [RFC6749]. Se applicabile, aggiunge le credenziali di autenticazione nell’intestazione o nel corpo secondo le stesse regole dell’endpoint del token.
Esempio (interruzioni di riga nel corpo solo per la visualizzazione):
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
Il server di autorizzazione DEVE elaborare la richiesta come segue:
-
Autenticare il client come all’endpoint del token (sezione 2.3 di [RFC6749]).
-
Rifiutare la richiesta se è presente il parametro
request_uri. -
Validare la richiesta inviata come una normale richiesta di autorizzazione (ad es. redirect URI e autorizzazione per lo scope). Il server PUÒ omettere passi non possibili durante il push; tali verifiche DEVONO poi essere effettuate all’endpoint di autorizzazione.
Il server di autorizzazione PUÒ consentire ai client con credenziali di stabilire redirect URI specifiche per ogni richiesta a ogni push (sezione 2.4), perché a differenza di [RFC6749] questa specifica permette autenticazione e validazione prima dell’esecuzione della richiesta di autorizzazione.