Passa al contenuto principale

4. DPoP Proof JWTs (JWT di Prova DPoP)

4. DPoP Proof JWTs (JWT di Prova DPoP)​

DPoP introduce il concetto di prova DPoP (DPoP proof), che è un JWT creato dal client e inviato con una richiesta HTTP utilizzando il campo di intestazione DPoP. Ogni richiesta HTTP richiede una prova DPoP unica.

Una prova DPoP valida dimostra al server che il client detiene la chiave privata utilizzata per firmare il JWT di prova DPoP. Ciò consente ai server di autorizzazione di vincolare i token emessi alla chiave pubblica corrispondente (come descritto nella Sezione 5) e consente ai server di risorse di verificare il vincolo della chiave dei token ricevuti (vedere Sezione 7.1), il che impedisce che detti token vengano utilizzati da qualsiasi entità che non ha accesso alla chiave privata.

Una prova DPoP dimostra il possesso di una chiave e non è, di per sé, un meccanismo di autenticazione o di controllo degli accessi. Quando presentata in combinazione con un token di accesso vincolato alla chiave, come descritto nella Sezione 7.1, una prova DPoP fornisce un'ulteriore garanzia riguardo alla legittimità del client che presenta il token di accesso. Tuttavia, un JWT di prova DPoP valido non è in alcun modo sufficiente da solo per prendere decisioni di controllo degli accessi.

4.1. L'intestazione HTTP DPoP​

Una prova DPoP è inclusa in una richiesta HTTP utilizzando il seguente campo di intestazione della richiesta:

DPoP: Un JWT conforme alla struttura e alla sintassi della Sezione 4.2.

La Figura 2 mostra un esempio di campo di intestazione HTTP DPoP. L'esempio utilizza "\" per il ritorno a capo, secondo [RFC8792].

DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

                    Figura 2: Esempio di Intestazione DPoP

Si noti che, secondo [RFC9110], i nomi dei campi di intestazione non fanno distinzione tra maiuscole e minuscole; quindi, DPoP, DPOP e dpop sono tutti nomi di campo di intestazione validi ed equivalenti. Tuttavia, la distinzione tra maiuscole e minuscole nel valore del campo di intestazione è significativa.

Il valore del campo di intestazione HTTP DPoP utilizza la sintassi token68 definita nella Sezione 11.2 di [RFC9110]. Per comodità, è riprodotto nella Figura 3.

DPoP       = token68
token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="

                   Figura 3: ABNF del Campo di Intestazione DPoP

4.2. Sintassi del JWT di Prova DPoP​

Una prova DPoP è un JWT [RFC7519] firmato (utilizzando JSON Web Signature (JWS) [RFC7515]) con una chiave privata scelta dal client (vedere sotto). L'intestazione JOSE di un JWT DPoP DEVE contenere almeno i seguenti parametri:

typ: Un campo con valore dpop+jwt, che tipizza esplicitamente il JWT di prova DPoP come raccomandato nella Sezione 3.11 di [RFC8725].

alg: Un identificatore di algoritmo di firma digitale asimmetrica JWS da [IANA.JOSE.ALGS]. NON DEVE essere none o un identificatore per un algoritmo simmetrico (Message Authentication Code (MAC)).

jwk: La chiave pubblica scelta dal client, in formato JSON Web Key (JWK) [RFC7517], come definito nella Sezione 4.1.3 di [RFC7515]. NON DEVE contenere la chiave privata.

Il payload di una prova DPoP DEVE contenere almeno i seguenti claim:

jti: Identificatore univoco per il JWT di prova DPoP. Il valore DEVE essere assegnato in modo tale che la probabilità che lo stesso valore venga assegnato a qualsiasi altra prova DPoP utilizzata nello stesso contesto durante il periodo di validità della prova sia trascurabile. Tale unicità può essere ottenuta codificando (base64url o qualsiasi altra codifica adatta) almeno 96 bit di dati pseudo-casuali o utilizzando una stringa Universally Unique Identifier (UUID) versione 4 secondo [RFC4122]. Il claim jti può essere utilizzato dal server per il rilevamento e la prevenzione del replay (vedere Sezione 11.1).

htm: Il valore del metodo HTTP ([RFC9110], Sezione 9.1) della richiesta a cui è allegato il JWT.

htu: Il valore dell'URI HTTP ([RFC9110], Sezione 7.1) della richiesta a cui è allegato il JWT, senza query e parti frammento.

iat: Timestamp di creazione del JWT ([RFC7519], Sezione 4.1.6).

Quando una prova DPoP viene utilizzata in combinazione con un token di accesso per accedere a una risorsa protetta (vedere Sezione 7), la prova DPoP DEVE contenere anche il seguente claim:

ath: Hash del token di accesso. Il valore DEVE essere il risultato di una codifica base64url (come definita nella Sezione 2 di [RFC7515]) dell'hash SHA-256 [SHS] della codifica ASCII del valore del token di accesso associato.

Quando il server di autorizzazione o il server di risorse fornisce un nonce tramite l'intestazione HTTP DPoP-Nonce (vedere le Sezioni 8 e 9), la prova DPoP DEVE contenere anche il seguente claim:

nonce: Un nonce recente fornito tramite l'intestazione HTTP DPoP-Nonce.

Una prova DPoP PUÒ contenere altri parametri di intestazione JOSE o claim secondo estensioni, profili o requisiti specifici di distribuzione.

La Figura 4 mostra un esempio concettuale del contenuto decodificato della prova DPoP nella Figura 2. Viene mostrato il JSON dell'intestazione JWT e del payload, ma la parte della firma è omessa. Come di consueto, sono inclusi interruzioni di riga e spazi aggiuntivi per formattazione e leggibilità.

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"-BwC3ESc6acc2lTc",
  "htm":"POST",
  "htu":"https://server.example.com/token",
  "iat":1562262616
}

            Figura 4: Esempio di Contenuto JWT di Prova DPoP

Della richiesta HTTP, solo il metodo HTTP e l'URI sono inclusi nel JWT DPoP, e quindi la prova DPoP copre solo queste due parti del messaggio. L'idea è di firmare solo abbastanza dati HTTP per fornire una prova di possesso ragionevole per la richiesta HTTP. Questo approccio di progettazione di utilizzare solo un sottoinsieme minimo di dati di intestazione HTTP evita le significative difficoltà inerenti a qualsiasi tentativo di inviare messaggi HTTP in forma canonica (canonicalization). Tuttavia, le prove DPoP possono essere estese per contenere altre informazioni dalla richiesta HTTP (vedere anche la Sezione 11.7).

4.3. Controllo delle Prove DPoP​

Per validare una prova DPoP, il server ricevente DEVE assicurarsi che:

  1. Ci sia un solo campo di intestazione richiesta HTTP DPoP.
  2. Il valore del campo di intestazione richiesta HTTP DPoP sia un singolo JWT ben formato.
  3. Tutti i claim richiesti elencati nella Sezione 4.2 siano contenuti nel JWT.
  4. Il valore del parametro di intestazione typ JOSE sia dpop+jwt.
  5. Il parametro di intestazione alg JOSE indichi un algoritmo di firma digitale asimmetrica registrato [IANA.JOSE.ALGS], non sia none, sia supportato dall'applicazione e sia accettabile secondo la politica locale.
  6. La firma JWT sia validata utilizzando la chiave pubblica contenuta nel parametro di intestazione jwk JOSE.
  7. Il parametro di intestazione jwk JOSE non contenga una chiave privata.
  8. Il claim htm corrisponda al metodo HTTP della richiesta corrente.
  9. Il claim htu corrisponda al valore dell'URI HTTP della richiesta HTTP in cui è stato ricevuto il JWT, ignorando le parti query e frammento.
  10. Se il server ha fornito un valore di nonce al client, il claim nonce corrisponda al valore di nonce fornito dal server.
  11. L'orario di creazione del JWT, determinato dal claim iat o dal timestamp gestito dal server tramite il claim nonce, sia entro una finestra temporale accettabile (vedere Sezione 11.1).
  12. Quando presentato a una risorsa protetta in combinazione con un token di accesso:
    • il valore del claim ath sia uguale all'hash di quel token di accesso, e
    • si assicuri che la chiave pubblica a cui è vincolato il token di accesso corrisponda alla chiave pubblica della prova DPoP.

Per ridurre la probabilità di falsi positivi, i server DOVREBBERO (SHOULD) impiegare la normalizzazione basata sulla sintassi ([RFC3986], Sezione 6.2.2) e la normalizzazione basata sullo schema ([RFC3986], Sezione 6.2.3) prima di confrontare il claim htu.

Questi controlli possono essere eseguiti in qualsiasi ordine.

Ultimo aggiornamento il