1. Introduction (Introduzione)

Il framework di autorizzazione OAuth 2.0 [RFC6749] consente alle applicazioni client di terze parti di ottenere accesso delegato alle risorse protette. Nel tipico flusso OAuth astratto illustrato nella figura 1, il client ottiene un access token da un'entità denominata authorization server e utilizza tale token quando accede alle risorse protette, ad esempio le API HTTPS.

  +--------+                                 +---------------+
  |        |                                 |               |
  |        |<--(A)-- Ottenere access token ->| Authorization |
  |        |                                 |     Server    |
  |        |                                 |               |
  |        |                                 +---------------+
  |        |                                         ^
  |        |                                         |
  |        |
  |        |                               (C)       |
  | Client |                         Validare
  |        |                         access token    |
  |        |
  |        |                                         |
  |        |                                         v
  |        |                                 +---------------+
  |        |                                 |      (C)      |
  |        |                                 |               |
  |        |<--(B)-- Usare access token ----->|   Risorsa     |
  |        |                                 |   protetta    |
  |        |                                 |               |
  +--------+                                 +---------------+

        Figura 1: Flusso astratto del protocollo OAuth 2.0

Il flusso illustrato nella figura 1 comprende i passaggi seguenti:

(A) Il client invia una richiesta HTTPS POST all'authorization server e presenta una credenziale che rappresenta l'authorization grant. Per determinati tipi di client (a cui sono stati rilasciati o che hanno altrimenti stabilito un insieme di client credentials) la richiesta DEVE essere autenticata. Nella risposta, l'authorization server rilascia un access token al client.

(B) Il client include l'access token quando effettua una richiesta per accedere a una risorsa protetta.

(C) La protected resource convalida l'access token al fine di autorizzare la richiesta. In alcuni casi, ad esempio quando il token è autocontenuto e protetto crittograficamente, la convalida può essere eseguita localmente dalla protected resource. In altri casi è necessario che la protected resource contatti l'authorization server per determinare lo stato del token e ottenere metainformazioni su di esso.

Sovrapponendosi al flusso astratto sopra, questo documento standardizza opzioni di sicurezza avanzate per OAuth 2.0 che utilizzano mutual TLS basato su client certificate. La sezione 2 fornisce opzioni per autenticare la richiesta nel passaggio (A). Il passaggio (C) è supportato da semantiche che esprimono il vincolo del token al client certificate sia per l'elaborazione locale che remota, rispettivamente nelle sezioni 3.1 e 3.2. Ciò garantisce che, come descritto nella sezione 3, l'accesso alla risorsa protetta nel passaggio (B) sia possibile solo per il client legittimo che usa un token vincolato al certificato e detiene la chiave privata corrispondente al certificato.

OAuth 2.0 definisce un metodo di autenticazione client basato su shared secret ma consente anche di definire e utilizzare meccanismi aggiuntivi di autenticazione client quando si interagisce direttamente con l'authorization server. Questo documento descrive un meccanismo aggiuntivo di autenticazione client che utilizza l'autenticazione mutual-TLS basata su certificato e offre caratteristiche di sicurezza migliori rispetto ai segreti condivisi. Mentre [RFC6749] documenta l'autenticazione client per le richieste al token endpoint, le estensioni di OAuth 2.0 (come Introspection [RFC7662], Revocation [RFC7009] e il Backchannel Authentication Endpoint in [OpenID.CIBA]) definiscono endpoint che utilizzano anch'essi l'autenticazione client, e i metodi mutual-TLS qui definiti sono applicabili anche a tali endpoint.

Gli access token vincolati al certificato mutual-TLS assicurano che solo la parte in possesso della chiave privata corrispondente al certificato possa utilizzare il token per accedere alle risorse associate. Tale vincolo è talvolta denominato key confirmation, proof-of-possession o holder-of-key e differisce dal caso del bearer token descritto in [RFC6750], in cui qualsiasi parte in possesso dell'access token può usarlo per accedere alle risorse associate. Vincolare un access token al certificato del client impedisce l'uso di token rubati o il replay di token da parte di soggetti non autorizzati.

Gli access token vincolati al certificato mutual-TLS e l'autenticazione client mutual-TLS sono meccanismi distinti, complementari, che non devono necessariamente essere distribuiti o usati insieme.

Questo documento introduce parametri aggiuntivi di client metadata a supporto degli access token vincolati al certificato e dell'autenticazione client mutual-TLS. L'authorization server può ottenere i client metadata tramite il Dynamic Client Registration Protocol [RFC7591], che definisce meccanismi per registrare dinamicamente i client metadata OAuth 2.0 presso gli authorization server. Inoltre i metadata definiti da [RFC7591] e le estensioni registrate ad essi associati implicano un modello dati generale per i client utile alle implementazioni dell'authorization server, anche quando il Dynamic Client Registration Protocol non è in uso. Tali implementazioni avranno in genere una qualche interfaccia utente per gestire la configurazione del client.

1. Introduction (Introduzione)​

1. Introduction (Introduzione)