7. Protected Resource Access (Accesso a Risorse Protette)

Per accedere alle risorse protette con DPoP, la richiesta deve contenere sia la prova DPoP descritta nella Sezione 4 sia il token di accesso descritto nella Sezione 7.1. La prova DPoP DEVE includere il claim ath con un valore hash valido per il token di accesso associato.

Vincolare il valore del token alla prova in questo modo impedisce che la prova di una richiesta venga utilizzata in un'altra richiesta con un valore di token di accesso diverso. Ad esempio, se un client detiene i token AT1 e AT2 legati a due diversi proprietari di risorse e utilizza la stessa chiave per le interazioni con il server di autorizzazione, questi token potrebbero essere scambiati. Senza il vincolo fornito dal campo ath, una firma catturata per AT1 potrebbe essere riprodotta con AT2 potenziando le autorizzazioni e l'accesso della richiesta prevista. Per i token di accesso che vengono ruotati all'interno della stessa combinazione client e proprietario della risorsa, tale prevenzione della sostituzione rimane efficace poiché ogni valore di token ruotato richiede il calcolo di una nuova prova. Questo vincolo garantisce inoltre che una prova destinata all'uso con un token di accesso non possa essere utilizzata senza quel token di accesso e viceversa.

Il server di risorse DEVE calcolare l'hash del valore del token presentato e verificare che sia identico al valore hash fornito nel campo ath (vedere Sezione 4.3). Poiché il valore del campo ath è coperto dalla firma della prova DPoP, la sua inclusione vincola il valore del token di accesso al proprietario della chiave utilizzata per generare la firma.

Si noti che il solo campo ath non protegge contro il replay della prova DPoP e non fornisce alcun vincolo alla richiesta con cui viene presentata la prova. La finestra di controllo della prova e i parametri del messaggio inclusi, come htm e htu, sono ancora importanti.

7.1. Schema di Autenticazione DPoP

Un token di accesso vincolato a DPoP viene inviato utilizzando il campo di intestazione della richiesta Authorization con lo schema di autenticazione DPoP secondo la Sezione 11.6.2 di [RFC9110]. La sintassi del campo di intestazione Authorization per lo schema DPoP utilizza la sintassi token68 definita nella Sezione 11.2 di [RFC9110] per le credenziali, riprodotta di seguito per comodità. La sintassi di notazione ABNF per le credenziali dello schema di autenticazione DPoP è la seguente:

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

credentials = "DPoP" 1*SP token68

              Figura 12: ABNF dello Schema di Autenticazione DPoP

Per tale token di accesso, un server di risorse DEVE verificare che sia stata ricevuta anche una prova DPoP nel campo di intestazione della richiesta DPoP della richiesta HTTP, controllare la prova DPoP secondo le regole nella Sezione 4.3 e verificare che la chiave pubblica della prova DPoP corrisponda alla chiave pubblica a cui è vincolato il token di accesso secondo la Sezione 6.

Il server di risorse NON DEVE concedere l'accesso alla risorsa a meno che tutti i controlli non abbiano successo.

La Figura 13 mostra una richiesta di esempio a una risorsa protetta con un token di accesso vincolato a DPoP nell'intestazione Authorization e la prova DPoP nell'intestazione DPoP. L'esempio utilizza "\" per il ritorno a capo, secondo [RFC8792]. Il contenuto decodificato di questa prova DPoP è mostrato nella Figura 14. 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 rientri per formattazione e leggibilità.

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj\
 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z\
 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF\
 c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E\
 OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

              Figura 13: Richiesta Risorsa Protetta con DPoP

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"e1j3V_bKic8-LAEB",
  "htm":"GET",
  "htu":"https://resource.example.org/protectedresource",
  "iat":1562262618,
  "ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

    Figura 14: Contenuto JWT di Prova DPoP Decodificato della Figura 13

Alla ricezione di una richiesta senza credenziali valide o con credenziali di accesso insufficienti per una risorsa protetta all'interno di uno spazio di protezione che richiede l'autenticazione DPoP, il server PUÒ inviare una risposta contenente una sfida (challenge) per sollecitare le credenziali di autenticazione DPoP dal client. Questa sfida viene inviata utilizzando il codice di stato della risposta 401 (Non autorizzato) ([RFC9110] Sezione 15.5.2) e il campo di intestazione WWW-Authenticate ([RFC9110] Sezione 11.6.1). Il server PUÒ includere l'intestazione WWW-Authenticate in risposta anche ad altre condizioni.

In tali sfide:

Il nome dello schema è DPoP.
Il parametro realm di autenticazione PUÒ essere incluso per indicare l'ambito di protezione nel modo descritto in [RFC9110] Sezione 11.5.
Il parametro scope di autenticazione definito in [RFC6750] Sezione 3 PUÒ essere incluso.
Il parametro error ([RFC6750] Sezione 3) DOVREBBE essere incluso per indicare il motivo per cui la richiesta è stata rifiutata, se la richiesta includeva un token di accesso ma non è riuscita nell'autenticazione. I valori del parametro error descritti in [RFC6750] Sezione 3.1 sono applicabili, così come qualsiasi valore appropriato definito dalle estensioni. Il valore use_dpop_nonce può essere utilizzato per segnalare che è richiesto un nonce nelle prove DPoP per le richieste successive, come descritto nella Sezione 9. Inoltre, invalid_dpop_proof viene utilizzato per indicare che la prova DPoP stessa è stata ritenuta non valida secondo i criteri della Sezione 4.3.
Il parametro error_description ([RFC6750] Sezione 3) PUÒ essere incluso insieme al parametro error per fornire una spiegazione leggibile dall'uomo destinata agli sviluppatori, che non deve essere mostrata agli utenti finali.
Un parametro algs DOVREBBE essere incluso per segnalare al client gli algoritmi JWS che possono essere utilizzati per i JWT di prova DPoP. Il valore di questo parametro è un elenco separato da spazi di valori di intestazione JWS alg (algoritmo) ([RFC7515] Sezione 4.1.1).
Possono essere utilizzati altri parametri di autenticazione; i parametri sconosciuti DEVONO essere ignorati dal destinatario.

La Figura 15 illustra una risposta a una richiesta per una risorsa protetta senza autenticazione.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP algs="ES256 PS256"

Figura 15: Risposta HTTP 401 a una richiesta di risorsa protetta senza autenticazione

La Figura 16 illustra una risposta a una richiesta di risorsa protetta che è stata rifiutata a causa della verifica fallita del vincolo DPoP del token di accesso. L'esempio utilizza "\" per il ritorno a capo, secondo [RFC8792].

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="invalid_token", \
   error_description="Invalid DPoP key binding", algs="ES256"

  Figura 16: Risposta HTTP 401 a una richiesta di risorsa protetta con token non valido

Si noti che le applicazioni client basate su browser che utilizzano la condivisione delle risorse tra le origini (CORS) [WHATWG.Fetch] avranno accesso solo alle intestazioni di risposta HTTP menzionate nell'elenco di sicurezza CORS per impostazione predefinita. Per consentire all'applicazione di accedere e utilizzare il valore dell'intestazione di risposta HTTP WWW-Authenticate, il server deve renderlo disponibile all'applicazione includendo WWW-Authenticate nel valore dell'elenco delle intestazioni di risposta Access-Control-Expose-Headers.

Questo schema di autenticazione è destinato esclusivamente all'autenticazione del server di origine. Pertanto, questo schema di autenticazione NON DEVE essere utilizzato con i campi di intestazione Proxy-Authenticate o Proxy-Authorization.

Si noti che la sintassi del campo di intestazione Authorization per questo schema di autenticazione segue l'utilizzo dello schema Bearer definito in [RFC6750] Sezione 2.1. Sebbene questa non sia la sintassi delle credenziali preferita di [RFC9110] Sezione 11.4, è compatibile con il framework di autenticazione generale ivi contenuto ed è utilizzata per coerenza e familiarità con lo schema Bearer.

7.2. Compatibilità con lo Schema di Autenticazione Bearer

Le risorse protette che supportano sia gli schemi DPoP che Bearer devono aggiornare le procedure per la valutazione dei token Bearer per impedire l'uso ridotto (downgrade usage) di token vincolati a DPoP. Nello specifico, tale risorsa protetta DEVE rifiutare un token di accesso vincolato a DPoP ricevuto come token Bearer (secondo [RFC6750]).

[RFC9110] Sezione 11.6.1 consente a una risorsa protetta di indicare il supporto per più schemi di autenticazione (ovvero Bearer e DPoP) tramite il campo di intestazione WWW-Authenticate di una risposta 401 (Non autorizzato).

Una risorsa protetta che supporta solo [RFC6750] e ignora DPoP accetterà molto probabilmente un token di accesso vincolato a DPoP come token Bearer (JWT [RFC7519] afferma che i claim non riconosciuti vengono ignorati, Introspection [RFC7662] afferma che altri parametri possono essere presenti ma non ha requisiti funzionali sulla loro presenza, e [RFC6750] tace effettivamente sul contenuto del token di accesso per quanto riguarda la validità). Un client può quindi inviare un token di accesso vincolato a DPoP utilizzando lo schema Bearer quando riceve una sfida WWW-Authenticate: Bearer da una risorsa protetta (o in qualsiasi momento, se ha una conoscenza precedente delle capacità della risorsa protetta). Ciò può semplificare la logistica per un aggiornamento graduale al supporto DPoP da parte delle risorse protette o implementazioni miste a lungo termine del supporto del tipo di token da parte delle risorse protette.

Se una risorsa protetta che supporta sia gli schemi Bearer che DPoP sceglie di rispondere con più sfide WWW-Authenticate, occorre prestare attenzione a quale sfida trasmette le informazioni sull'errore effettive. Si raccomanda di seguire le seguenti regole:

Se la richiesta non conteneva credenziali, le sfide non dovrebbero includere codici di errore o altre informazioni sull'errore come descritto in [RFC6750] Sezione 3.1 (Figura 17).
Se il meccanismo con cui è stata tentata l'autenticazione può essere stabilito chiaramente, la sfida corrispondente dovrebbe essere utilizzata per trasmettere le informazioni sull'errore (Figura 18).
Altrimenti, entrambe le sfide Bearer e DPoP possono essere utilizzate per trasmettere informazioni sull'errore (Figura 19).

Gli esempi seguenti utilizzano "\" per il ritorno a capo, secondo [RFC8792].

GET /protectedresource HTTP/1.1
Host: resource.example.org

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer, DPoP algs="ES256 PS256"

 Figura 17: Risposta HTTP 401 a una richiesta di risorsa protetta senza autenticazione

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer INVALID_TOKEN

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", \
    error_description="Invalid token", DPoP algs="ES256 PS256"

  Figura 18: Risposta HTTP 401 a una richiesta di risorsa protetta con autenticazione non valida

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer error="invalid_request", \
 error_description="Multiple methods used to include access token", \
 DPoP algs="ES256 PS256", error="invalid_request", \
 error_description="Multiple methods used to include access token"

  Figura 19: Risposta HTTP 400 a una richiesta di risorsa protetta con autenticazione ambigua

7.3. Considerazioni sul Client

Le richieste di autorizzazione contenenti prove DPoP potrebbero non essere idempotenti (a seconda dell'applicazione da parte del server dei claim jti, iat e nonce), rendendo le richieste alle risorse protette che erano precedentemente idempotenti, ora potenzialmente non più idempotenti. Si suggerisce che i client generino prove DPoP uniche anche per tentativi di richieste idempotenti in risposta a quelli che sono tipicamente intesi come errori HTTP transitori.

I client che riscontrano frequentemente errori di rete potrebbero dover affrontare ulteriori sfide durante l'interazione con i server che implementano una convalida del nonce più rigorosa.