3. Concept (Concetto)

3. Concept (Concetto)

La principale struttura dati introdotta da questa specifica è il JWT di prova DPoP (DPoP proof JWT), inviato come intestazione in una richiesta HTTP, come descritto di seguito. Il client utilizza un JWT di prova DPoP per dimostrare di possedere la chiave privata corrispondente a una determinata chiave pubblica.

In parole povere, una prova DPoP è una firma su:

• alcuni dati della richiesta HTTP a cui è allegata,

• un timestamp,

• un identificatore univoco,

• un nonce opzionale fornito dal server, e

• un hash del token di accesso associato, quando un token di accesso è presente nella richiesta.

+--------+                                          +---------------+
|        |--(A)-- Richiesta Token ----------------->|               |
| Client |        (Prova DPoP)                      | Server di     |
|        |                                          | Autorizzazione|
|        |<-(B)-- Token di accesso legato a DPoP ---|               |
|        |        (token_type=DPoP)                 +---------------+
|        |
|        |
|        |                                          +---------------+
|        |--(C)-- Token di accesso legato a DPoP -->|               |
|        |        (Prova DPoP)                      | Server di     |
|        |                                          | Risorse       |
|        |<-(D)-- Risorsa Protetta -----------------|               |
|        |                                          +---------------+
+--------+

                      Figura 1: Flusso DPoP di Base

I passaggi fondamentali di un flusso OAuth con DPoP (senza il nonce opzionale) sono mostrati nella Figura 1.

A. In una richiesta di token, il client invia una concessione di autorizzazione (ad esempio, un codice di autorizzazione, un token di aggiornamento, ecc.) al server di autorizzazione per ottenere un token di accesso (e possibilmente un token di aggiornamento). Il client allega una prova DPoP alla richiesta in un'intestazione HTTP.

B. Il server di autorizzazione vincola (impone il vincolo al mittente) il token di accesso alla chiave pubblica che il client ha rivendicato nella prova DPoP; ovvero, il token di accesso non può essere utilizzato senza dimostrare il possesso della chiave privata corrispondente. Se viene emesso un token di aggiornamento a un client pubblico, anch'esso viene vincolato alla chiave pubblica della prova DPoP.

C. Per utilizzare il token di accesso, il client deve dimostrare il possesso della chiave privata aggiungendo nuovamente un'intestazione contenente una prova DPoP della richiesta alla richiesta. Il server di risorse deve ricevere informazioni sulla chiave pubblica a cui è vincolato il token di accesso. Queste informazioni possono essere codificate direttamente nel token di accesso (per i token di accesso strutturati JWT) o fornite tramite l'endpoint di introspezione del token (non mostrato). Il server di risorse verifica che la chiave pubblica a cui è vincolato il token di accesso corrisponda alla chiave pubblica della prova DPoP. Verifica inoltre che l'hash del token di accesso nella prova DPoP corrisponda al token di accesso presentato nella richiesta.

D. Se la verifica della firma fallisce o i dati nella prova DPoP non sono corretti (ad esempio, l'URI di destinazione non corrisponde al claim URI nel JWT di prova DPoP), il server di risorse rifiuta di servire la richiesta. Il token di accesso stesso deve, ovviamente, essere valido anche sotto tutti gli altri aspetti.

Il meccanismo DPoP qui proposto non è un metodo di autenticazione client. Infatti, uno dei casi d'uso principali per DPoP riguarda i client pubblici (ad esempio, "single page applications" e applicazioni sui dispositivi degli utenti) che non utilizzano l'autenticazione client. Tuttavia, DPoP è progettato per essere compatibile con private_key_jwt e tutti gli altri metodi di autenticazione client.

DPoP non garantisce direttamente l'integrità dei messaggi, ma si affida al livello TLS per questo scopo. Vedere la Sezione 11 per maggiori dettagli.