1. Introduction (Introduzione)

1. Introduction (Introduzione)

Questo documento definisce l’endpoint pushed authorization request (PAR), che consente a un client OAuth [RFC6749] di inviare direttamente al server di autorizzazione il payload di una richiesta di autorizzazione. In cambio riceve un URI di richiesta che fa da riferimento ai dati del payload in una successiva chiamata all’endpoint di autorizzazione tramite l’user agent.

In OAuth [RFC6749] i parametri della richiesta di autorizzazione sono in genere inviati come parametri di query nell’URI mediante reindirizzamento nell’user agent. È semplice, ma presenta difficoltà:

• Non c’è protezione crittografica di integrità o autenticità. Un attaccante potrebbe ad esempio modificare lo scope richiesto o sostituire il contesto di una transazione di pagamento alterando i valori di scope. Sebbene il protocollo offra mezzi per rilevare alcune modifiche, impedirle precocemente nel flusso è più robusto.

• Non esiste un meccanismo che garantisca la riservatezza dei parametri. Anche se HTTPS è richiesto per l’endpoint di autorizzazione, i dati della richiesta transitano in chiaro nell’user agent e le stringhe di query possono finire involontariamente nei log del server web o su altri siti tramite il referrer. L’impatto può essere rilevante se nella richiesta di autorizzazione sono inclusi dati personali o soggetti a normativa (come in scenari di identità o open banking).

• Gli URL di richiesta di autorizzazione possono diventare molto lunghi, in particolare con dati di autorizzazione granulari, con possibili errori di elaborazione.

JWT-Secured Authorization Request (JAR) [RFC9101] affronta le sfide di sicurezza consentendo ai client OAuth di incapsulare i parametri in un Request Object, un JSON Web Token (JWT) [RFC7519] firmato e opzionalmente crittografato. Per i limiti di dimensione JAR introduce il parametro request_uri, che consente di inviare un riferimento all’oggetto anziché l’oggetto stesso.

Questo documento completa JAR fornendo un modo interoperabile per inviare direttamente il payload al server di autorizzazione in cambio di un valore request_uri utilizzabile sul server in una successiva richiesta di autorizzazione.

PAR rafforza la sicurezza di OAuth offrendo ai client un modo semplice per ottenere una richiesta di autorizzazione riservata e protetta in integrità. I client che richiedono un livello di sicurezza ancora più elevato, in particolare non ripudio dimostrato crittograficamente, possono usare Request Object basati su JWT come definiti in [RFC9101] insieme a PAR.

PAR consente al server di autorizzazione di autenticare il client prima di qualsiasi interazione con l’utente. La maggiore fiducia nell’identità del client durante il flusso permette al server di rifiutare molto prima le richieste illegittime, mitigando spoofing del client o altre manipolazioni o abusi della richiesta di autorizzazione.

Si noti che richieste HTTP POST all’endpoint di autorizzazione tramite user agent, come descritto nella sezione 3.1 di [RFC6749] e nella sezione 3.1.2.1 di [OIDC], potrebbero affrontare i limiti di dimensione sopra citati. Tuttavia sono opzionali secondo [RFC6749] e, anche se supportate, sono praticabili per le applicazioni web classiche ma proibitive per le app mobili installate. Come descritto in [RFC8252], tali app usano API specifiche della piattaforma per aprire l’URI di autorizzazione nel browser di sistema; la richiesta iniziale risultante è limitata al metodo GET. Usare POST per la richiesta di autorizzazione richiederebbe prima di dirigere il browser verso un URI controllato dall’app con GET trasmettendo in qualche modo il payload voluminoso, poi una risposta con contenuto e script per avviare un POST cross-site al server di autorizzazione. PAR è più semplice da usare e offre ulteriori vantaggi di sicurezza, come indicato sopra.

Vedere 1.1. Introductory Example (Esempio introduttivo) e 1.2. Conventions and Terminology (Convenzioni e terminologia).