5. DPoP Access Token Request (Richiesta di Token di Accesso DPoP)

Per richiedere un token di accesso vincolato a una chiave pubblica utilizzando DPoP, il client DEVE fornire un JWT di prova DPoP valido in un'intestazione DPoP quando effettua una richiesta di token di accesso all'endpoint del token del server di autorizzazione. Ciò si applica a tutte le richieste di token di accesso indipendentemente dal tipo di concessione (ad esempio, i tipi di concessione comuni authorization_code e refresh_token, nonché tipi di concessione di estensione come la Concessione di Autorizzazione JWT [RFC7523]). La richiesta HTTP nella Figura 5 illustra tale richiesta di token di accesso utilizzando la concessione del codice di autorizzazione e includendo un JWT di prova DPoP nell'intestazione DPoP. L'esempio utilizza "\" per il ritorno a capo, secondo [RFC8792].

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

grant_type=authorization_code\
&client_id=s6BhdRkqt\
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
&code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz-

 Figura 5: Richiesta di Token che richiede un token vincolato al mittente DPoP utilizzando un codice di autorizzazione

Il campo di intestazione HTTP DPoP DEVE contenere un JWT di prova DPoP valido. Se la prova DPoP non è valida, il server di autorizzazione restituisce una risposta di errore come descritto nella Sezione 5.2 di [RFC6749], con valore del parametro error di invalid_dpop_proof.

Dopo aver verificato la prova DPoP come valida, il server di autorizzazione associa il token di accesso emesso alla chiave pubblica della prova DPoP per vincolare al mittente il token di accesso. Questo può essere fatto come descritto nella Sezione 6. La risposta del token di accesso DEVE includere un token_type di DPoP per indicare al client che il token di accesso è stato vincolato alla chiave DPoP e può essere utilizzato come descritto nella Sezione 7.1. La risposta di esempio nella Figura 6 illustra tale risposta.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
 "access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU",
 "token_type": "DPoP",
 "expires_in": 2677,
 "refresh_token": "Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g"
}

                   Figura 6: Risposta Token di Accesso

La risposta di esempio nella Figura 6 include un token di aggiornamento che il client può utilizzare per ottenere un nuovo token di accesso quando quello vecchio scade. L'aggiornamento di un token di accesso è una richiesta di token all'endpoint del token del server di autorizzazione utilizzando il tipo di concessione refresh_token. Come per tutte le richieste di token di accesso, il client effettua questa una richiesta DPoP includendo una prova DPoP, come mostrato nella Figura 7. L'esempio utilizza "\" per il ritorno a capo, secondo [RFC8792].

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjY1Mjk2fQ.pAqut2IRDm_De6PR93SYmGBPXpwrAk90e8cP2hjiaG5Qs\
 GSuKDYW7_X620BxqhvYC8ynrrvZLTk41mSRroapUA

grant_type=refresh_token\
&client_id=s6BhdRkqt\
&refresh_token=Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g

 Figura 7: Richiesta di Token che richiede un token legato a DPoP utilizzando un token di aggiornamento

Quando un server di autorizzazione che supporta DPoP emette un token di aggiornamento a un client pubblico che presenta una prova DPoP valida all'endpoint del token, il token di aggiornamento DEVE essere vincolato alla chiave pubblica corrispondente. Quando il token di aggiornamento viene successivamente utilizzato per ottenere un nuovo token di accesso, tale vincolo DEVE essere convalidato. Un tale client DEVE quindi presentare una prova DPoP con la stessa chiave utilizzata per ottenere il token di aggiornamento ogni volta che tale token di aggiornamento viene utilizzato per ottenere un nuovo token di accesso. I dettagli dell'implementazione del vincolo del token di aggiornamento sono a discrezione del server di autorizzazione; non ci sono considerazioni sull'interoperabilità per i dettagli specifici del vincolo poiché è il server di autorizzazione a generare e convalidare il token di aggiornamento.

Il server di autorizzazione PUÒ scegliere di emettere un token di accesso non vincolato a DPoP utilizzando il valore Bearer ([RFC6750]) nel parametro token_type della risposta del token di accesso. Per i client pubblici che ottengono anche un token di aggiornamento, ciò ha ancora l'effetto di vincolare a DPoP solo il token di aggiornamento, il che può comunque migliorare la postura di sicurezza anche se le risorse protette non vengono aggiornate per supportare DPoP.

Se la risposta del token di accesso contiene un valore token_type diverso da DPoP, il client non ottiene la protezione del token di accesso offerta da DPoP. Se tale protezione è importante per la sicurezza dell'applicazione, il client DEVE scartare la risposta. Altrimenti, il client può procedere come con una normale interazione OAuth.

I token di aggiornamento emessi a client confidenziali (ovvero client che hanno stabilito credenziali di autenticazione con il server di autorizzazione) NON SONO vincolati alla chiave pubblica della prova DPoP perché sono già vincolati al mittente tramite un diverso meccanismo esistente. Il framework di autorizzazione OAuth 2.0 [RFC6749] richiede già che il server di autorizzazione vincoli i token di aggiornamento al client a cui sono stati emessi, e i client confidenziali si autenticano al server di autorizzazione quando presentano il token di aggiornamento. Di conseguenza, tali token di aggiornamento sono vincolati al mittente in virtù dell'identità del client e del requisito di autenticazione associato. Questo meccanismo di vincolo al mittente esistente è più flessibile di un vincolo diretto a una specifica chiave pubblica (consente ad esempio la rotazione delle credenziali del client senza invalidare i token di aggiornamento).

5.1. Metadati del Server di Autorizzazione

Questo documento introduce i seguenti parametri di metadati del server di autorizzazione [RFC8414] per segnalare il supporto generale per DPoP e i valori alg JWS specifici supportati dal server di autorizzazione per i JWT di prova DPoP.

dpop_signing_alg_values_supported: Un array JSON contenente un elenco dei valori alg JWS (dal registro [IANA.JOSE.ALGS]) supportati dal server di autorizzazione per i JWT di prova DPoP.

5.2. Metadati di Registrazione Client

Il protocollo di Registrazione Client Dinamica [RFC7591] definisce un'API per i client per registrare dinamicamente i metadati OAuth 2.0 con i server di autorizzazione. I metadati definiti da [RFC7591] e le estensioni di registrazione ad esso suggeriscono anche un modello di dati client generale utile per le implementazioni dei server di autorizzazione, anche quando il protocollo di registrazione client dinamica non è in uso. Tipicamente, tali implementazioni hanno un'interfaccia utente per la gestione della configurazione del client.

Questo documento introduce il seguente parametro di metadati di registrazione client [RFC7591] per indicare che il client utilizzerà sempre DPoP quando richiede token al server di autorizzazione:

dpop_bound_access_tokens: Valore booleano che specifica se il client utilizzerà sempre DPoP per le richieste di token. Se omesso, il valore predefinito è false.

Se true, il server di autorizzazione DEVE rifiutare le richieste di token da questo client che non contengono l'intestazione DPoP.