1. Introduction (Introduzione)
1. Introduction (Introduzione)
La Dimostrazione del Possesso (Demonstrating Proof of Possession - DPoP) è un meccanismo a livello applicativo per vincolare al mittente (sender-constraining) i token di accesso e di aggiornamento OAuth [RFC6749]. Consente ai client di dimostrare il possesso di una coppia di chiavi pubblica/privata includendo un'intestazione DPoP in una richiesta HTTP. Il valore dell'intestazione è un JSON Web Token (JWT) [RFC7519] che consente al server di autorizzazione di vincolare i token emessi alla parte pubblica della coppia di chiavi del client. I destinatari di tali token sono quindi in grado di verificare il vincolo del token alla coppia di chiavi di cui il client ha dimostrato il possesso tramite l'intestazione DPoP, fornendo così la certezza che il client che presenta il token possiede anche la chiave privata. In altre parole, il legittimo detentore del token è vincolato a essere il mittente che detiene e dimostra il possesso della parte privata della coppia di chiavi.
Il meccanismo qui specificato può essere utilizzato nei casi in cui altri metodi per vincolare al mittente i token utilizzando elementi del sottostante livello di trasporto sicuro (come [RFC8705] o [TOKEN-BINDING]) non sono disponibili o desiderabili. Ad esempio, nessuno di questi metodi può essere utilizzato se il client OAuth è un'applicazione scaricata dinamicamente ed eseguita in un browser web (a volte indicata come "applicazione a pagina singola") a causa di una scarsa esperienza utente per l'autenticazione client TLS negli user agent e la mancanza di supporto per HTTP Token Binding. Inoltre, le applicazioni installate ed eseguite direttamente su un dispositivo utente sono ben posizionate per beneficiare dei token legati a DPoP per impedire l'uso improprio di token compromessi da risorse dannose o compromesse. Tali applicazioni in genere dispongono di un'archiviazione sicura dedicata per le chiavi crittografiche.
DPoP può essere utilizzato per vincolare al mittente i token di accesso indipendentemente dal metodo di autenticazione del client utilizzato; tuttavia, DPoP non viene utilizzato per l'autenticazione del client in sé. DPoP può anche essere utilizzato per vincolare al mittente i token di aggiornamento emessi a client pubblici (ovvero client senza credenziali di autenticazione associate a un client_id).
1.1. Convenzioni e terminologia
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] quando appaiono in tutte maiuscole, come mostrato qui.
Questa specifica utilizza la notazione Augmented Backus-Naur Form (ABNF) di [RFC5234].
Questa specifica utilizza i termini "token di accesso" (access token), "token di aggiornamento" (refresh token), "server di autorizzazione" (authorization server), "server di risorse" (resource server), "endpoint di autorizzazione" (authorization endpoint), "richiesta di autorizzazione" (authorization request), "risposta di autorizzazione" (authorization response), "endpoint del token" (token endpoint), "tipo di concessione" (grant type), "richiesta di token di accesso" (access token request), "risposta di token di accesso" (access token response), "client", "client pubblico" (public client) e "client confidenziale" (confidential client) definiti da "The OAuth 2.0 Authorization Framework" [RFC6749].
I termini "richiesta" (request), "risposta" (response), "campo di intestazione" (header field) e "URI di destinazione" (target URI) sono tratti da [RFC9110].
I termini "JOSE" e "Intestazione JOSE" (JOSE Header) sono tratti da [RFC7515].
Questo documento contiene esempi non normativi di messaggi HTTP parziali e completi. Alcuni esempi utilizzano una singola barra rovesciata per indicare il ritorno a capo per valori lunghi, secondo [RFC8792]. La barra rovesciata di a capo, così come la nuova riga successiva e lo spazio iniziale, non fanno parte del valore.