1. Introduzione (Introduction)
Nel modello tradizionale di autenticazione client-server, il client richiede una risorsa ad accesso limitato (risorsa protetta) sul server autenticandosi presso il server con le credenziali del proprietario della risorsa. Per fornire ad applicazioni di terze parti l'accesso a risorse riservate, il proprietario della risorsa condivide le proprie credenziali con la terza parte. Questo crea diversi problemi e limitazioni:
- le applicazioni di terze parti devono conservare le credenziali del proprietario della risorsa per un uso futuro, tipicamente una password in chiaro;
- i server devono supportare l'autenticazione con password, nonostante le debolezze di sicurezza intrinseche delle password;
- le applicazioni di terze parti ottengono un accesso eccessivamente ampio alle risorse protette del proprietario della risorsa, lasciandolo senza la possibilità di limitarne la durata o di restringere l'accesso a un sottoinsieme di risorse;
- i proprietari delle risorse non possono revocare l'accesso a una singola terza parte senza revocare l'accesso a tutte le terze parti, e devono farlo cambiando la password della terza parte;
- la compromissione di qualsiasi applicazione di terze parti comporta la compromissione della password dell'utente finale e di tutti i dati protetti da tale password.
OAuth affronta questi problemi introducendo un livello di autorizzazione e separando il ruolo del client da quello del proprietario della risorsa. In OAuth, il client richiede l'accesso a risorse controllate dal proprietario della risorsa e ospitate dal server delle risorse, e riceve un insieme di credenziali diverso da quello del proprietario della risorsa.
Invece di usare le credenziali del proprietario della risorsa per accedere alle risorse protette, il client ottiene un token di accesso -- una stringa che indica uno specifico ambito, una durata e altri attributi di accesso. I token di accesso sono emessi ai client di terze parti da un server di autorizzazione con l'approvazione del proprietario della risorsa. Il client usa il token di accesso per accedere alle risorse protette ospitate dal server delle risorse.
Per esempio, un'utente finale (proprietaria della risorsa) può concedere a un servizio di stampa (client) l'accesso alle sue foto protette memorizzate presso un servizio di condivisione foto (server delle risorse), senza condividere nome utente e password con il servizio di stampa. Invece, si autentica direttamente presso un server considerato attendibile dal servizio di condivisione foto (server di autorizzazione), che rilascia al servizio di stampa credenziali specifiche per la delega (token di accesso).
Questa specifica è progettata per l'uso con HTTP ([RFC2616]). L'uso di OAuth su qualsiasi protocollo diverso da HTTP è fuori dall'ambito di questa specifica.
Il protocollo OAuth 1.0 ([RFC5849]), pubblicato come documento informativo, è stato il risultato di un piccolo sforzo comunitario ad hoc. Questa specifica Standards Track si basa sull'esperienza di distribuzione di OAuth 1.0, nonché su casi d'uso aggiuntivi e requisiti di estensibilità raccolti dalla più ampia comunità IETF. Il protocollo OAuth 2.0 non è retrocompatibile con OAuth 1.0. Le due versioni possono coesistere sulla rete e le implementazioni possono scegliere di supportarle entrambe. Tuttavia, l'intento di questa specifica è che le nuove implementazioni supportino OAuth 2.0 come specificato in questo documento e che OAuth 1.0 sia usato solo per supportare distribuzioni esistenti. OAuth 2.0 condivide pochissimi dettagli implementativi con OAuth 1.0. Gli implementatori che conoscono OAuth 1.0 dovrebbero affrontare questo documento senza supposizioni sulla sua struttura e sui suoi dettagli.
1.1. Ruoli (Roles)
OAuth definisce quattro ruoli:
proprietario della risorsa (Resource Owner)
Un'entità capace di concedere l'accesso a una risorsa protetta. Quando il proprietario della risorsa è una persona, viene chiamato utente finale.
server delle risorse (Resource Server)
Il server che ospita le risorse protette, capace di accettare e rispondere a richieste di risorse protette usando token di accesso.
client
Un'applicazione che effettua richieste di risorse protette per conto del proprietario della risorsa e con la sua autorizzazione. Il termine "client" non implica alcuna particolare caratteristica implementativa, per esempio se l'applicazione sia eseguita su un server, su un desktop o su altri dispositivi.
server di autorizzazione (Authorization Server)
Il server che emette token di accesso al client dopo aver autenticato con successo il proprietario della risorsa e ottenuto l'autorizzazione.
L'interazione tra il server di autorizzazione e il server delle risorse è fuori dall'ambito di questa specifica. Il server di autorizzazione può essere lo stesso server del server delle risorse o un'entità separata. Un singolo server di autorizzazione può emettere token di accesso accettati da più server delle risorse.
1.2. Flusso del protocollo (Protocol Flow)
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figura 1: Flusso astratto del protocollo
Il flusso astratto OAuth 2.0 illustrato nella Figura 1 descrive l'interazione tra i quattro ruoli e comprende i seguenti passi:
(A) Il client richiede l'autorizzazione al proprietario della risorsa. La richiesta di autorizzazione può essere effettuata direttamente al proprietario della risorsa, come mostrato, o preferibilmente indirettamente tramite il server di autorizzazione come intermediario.
(B) Il client riceve un'autorizzazione, cioè una credenziale che rappresenta l'autorizzazione del proprietario della risorsa, espressa usando uno dei quattro tipi di grant definiti in questa specifica o un tipo di grant di estensione. Il tipo di grant dipende dal metodo usato dal client per richiedere l'autorizzazione e dai tipi supportati dal server di autorizzazione.
(C) Il client richiede un token di accesso autenticandosi presso il server di autorizzazione e presentando l'autorizzazione.
(D) Il server di autorizzazione autentica il client e valida l'autorizzazione; se è valida, emette un token di accesso.
(E) Il client richiede la risorsa protetta al server delle risorse e si autentica presentando il token di accesso.
(F) Il server delle risorse valida il token di accesso e, se è valido, serve la richiesta.
Il metodo preferito per ottenere un'autorizzazione dal proprietario della risorsa (passi (A) e (B)) consiste nell'usare il server di autorizzazione come intermediario, come illustrato nella Figura 3 della Sezione 4.1.
1.3. Autorizzazione (Authorization Grant)
Un'autorizzazione è una credenziale che rappresenta l'autorizzazione del proprietario della risorsa, usata dal client per ottenere un token di accesso. Questa specifica definisce quattro tipi di grant -- codice di autorizzazione, implicito, credenziali password del proprietario della risorsa e credenziali del client -- oltre a un meccanismo di estensibilità per definire tipi aggiuntivi.
1.3.1. Codice di autorizzazione (Authorization Code)
Il codice di autorizzazione viene ottenuto usando un server di autorizzazione come intermediario tra il client e il proprietario della risorsa. Invece di richiedere l'autorizzazione direttamente al proprietario della risorsa, il client indirizza il proprietario della risorsa a un server di autorizzazione tramite il suo user-agent, come definito in [RFC2616], e il server reindirizza poi il proprietario della risorsa al client con il codice di autorizzazione.
Prima di reindirizzare il proprietario della risorsa al client con il codice di autorizzazione, il server di autorizzazione autentica il proprietario della risorsa e ottiene l'autorizzazione. Poiché il proprietario della risorsa si autentica solo presso il server di autorizzazione, le sue credenziali non sono mai condivise con il client.
Il codice di autorizzazione offre alcuni importanti vantaggi di sicurezza, come la possibilità di autenticare il client e la trasmissione del token di accesso direttamente al client senza farlo passare attraverso lo user-agent del proprietario della risorsa ed esporlo potenzialmente ad altri, incluso il proprietario della risorsa.
1.3.2. Implicito (Implicit)
Il grant implicito è un flusso di codice di autorizzazione semplificato, ottimizzato per client implementati in un browser usando un linguaggio di script come JavaScript. Nel flusso implicito, invece di ricevere un codice di autorizzazione, il client riceve direttamente un token di accesso come risultato dell'autorizzazione del proprietario della risorsa. Il tipo di grant è implicito perché non vengono emesse credenziali intermedie, come un codice di autorizzazione, da usare successivamente per ottenere un token di accesso.
Quando emette un token di accesso durante il flusso implicito, il server di autorizzazione non autentica il client. In alcuni casi, l'identità del client può essere verificata tramite l'URI di reindirizzamento usato per consegnare il token di accesso al client. Il token di accesso può essere esposto al proprietario della risorsa o ad altre applicazioni che hanno accesso allo user-agent del proprietario della risorsa.
I grant impliciti migliorano la reattività e l'efficienza di alcuni client, ad esempio un client implementato come applicazione nel browser, poiché riducono il numero di round trip necessari per ottenere un token di accesso. Tuttavia, questa comodità deve essere valutata rispetto alle implicazioni di sicurezza dell'uso dei grant impliciti, come quelle descritte nelle Sezioni 10.3 e 10.16, soprattutto quando è disponibile il tipo di grant con codice di autorizzazione.
1.3.3. Credenziali password del proprietario della risorsa
Le credenziali password del proprietario della risorsa, cioè nome utente e password, possono essere usate direttamente come autorizzazione per ottenere un token di accesso. Le credenziali dovrebbero essere usate solo quando esiste un alto grado di fiducia tra il proprietario della risorsa e il client, per esempio quando il client fa parte del sistema operativo del dispositivo o è un'applicazione altamente privilegiata, e quando non sono disponibili altri tipi di grant, come il codice di autorizzazione.
Anche se questo tipo di grant richiede l'accesso diretto del client alle credenziali del proprietario della risorsa, tali credenziali sono usate per una singola richiesta e scambiate con un token di accesso. Questo tipo di grant può eliminare la necessità per il client di memorizzare le credenziali del proprietario della risorsa per uso futuro, scambiandole con un token di accesso o un token di aggiornamento di lunga durata.
1.3.4. Credenziali del client (Client Credentials)
Le credenziali del client, o altre forme di autenticazione del client, possono essere usate come autorizzazione quando l'ambito dell'autorizzazione è limitato alle risorse protette sotto il controllo del client o a risorse protette concordate in precedenza con il server di autorizzazione. Le credenziali del client sono tipicamente usate come autorizzazione quando il client agisce per proprio conto, cioè quando il client è anche il proprietario della risorsa, o quando richiede accesso a risorse protette sulla base di un'autorizzazione concordata in precedenza con il server di autorizzazione.
1.4. Token di accesso (Access Token)
I token di accesso sono credenziali usate per accedere a risorse protette. Un token di accesso è una stringa che rappresenta un'autorizzazione emessa al client. La stringa è solitamente opaca per il client. I token rappresentano specifici ambiti e durate di accesso, concessi dal proprietario della risorsa e fatti rispettare dal server delle risorse e dal server di autorizzazione.
Il token può indicare un identificatore usato per recuperare le informazioni di autorizzazione oppure può contenere direttamente tali informazioni in modo verificabile, per esempio una stringa composta da dati e una firma. Per consentire al client di usare un token possono essere richieste credenziali di autenticazione aggiuntive, fuori dall'ambito di questa specifica.
Il token di accesso fornisce un livello di astrazione, sostituendo diverse costruzioni di autorizzazione, come nome utente e password, con un singolo token compreso dal server delle risorse. Questa astrazione consente di emettere token di accesso più restrittivi dell'autorizzazione usata per ottenerli e rimuove la necessità per il server delle risorse di comprendere un'ampia gamma di metodi di autenticazione.
I token di accesso possono avere formati, strutture e metodi di utilizzo differenti, per esempio proprietà crittografiche, in base ai requisiti di sicurezza del server delle risorse. Gli attributi dei token di accesso e i metodi usati per accedere alle risorse protette sono fuori dall'ambito di questa specifica e sono definiti da specifiche complementari come [RFC6750].
1.5. Token di aggiornamento (Refresh Token)
I token di aggiornamento sono credenziali usate per ottenere token di accesso. Sono emessi al client dal server di autorizzazione e sono usati per ottenere un nuovo token di accesso quando quello corrente diventa non valido o scade, oppure per ottenere token di accesso aggiuntivi con ambito identico o più ristretto. I token di accesso possono avere una durata più breve e meno permessi rispetto a quanto autorizzato dal proprietario della risorsa. L'emissione di un token di aggiornamento è facoltativa ed è a discrezione del server di autorizzazione. Se il server di autorizzazione emette un token di aggiornamento, lo include quando emette un token di accesso, cioè al passo (D) della Figura 1.
Un token di aggiornamento è una stringa che rappresenta l'autorizzazione concessa al client dal proprietario della risorsa. La stringa è solitamente opaca per il client. Il token indica un identificatore usato per recuperare le informazioni di autorizzazione. A differenza dei token di accesso, i token di aggiornamento sono destinati all'uso solo con i server di autorizzazione e non vengono mai inviati ai server delle risorse.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figura 2: Aggiornamento di un token di accesso scaduto
Il flusso illustrato nella Figura 2 comprende:
(A) Il client richiede un token di accesso autenticandosi presso il server di autorizzazione e presentando un'autorizzazione.
(B) Il server di autorizzazione autentica il client e valida l'autorizzazione; se è valida, emette un token di accesso e un token di aggiornamento.
(C) Il client effettua una richiesta di risorsa protetta al server delle risorse presentando il token di accesso.
(D) Il server delle risorse valida il token di accesso e, se è valido, serve la richiesta.
(E) I passi (C) e (D) si ripetono finché il token di accesso scade. Se il client sa che il token di accesso è scaduto, passa al passo (G); altrimenti effettua un'altra richiesta di risorsa protetta.
(F) Poiché il token di accesso non è valido, il server delle risorse restituisce un errore di token non valido.
(G) Il client richiede un nuovo token di accesso autenticandosi presso il server di autorizzazione e presentando il token di aggiornamento. I requisiti di autenticazione del client dipendono dal tipo di client e dalle politiche del server di autorizzazione.
(H) Il server di autorizzazione autentica il client e valida il token di aggiornamento; se è valido, emette un nuovo token di accesso e, facoltativamente, un nuovo token di aggiornamento.
I passi (C), (D), (E) e (F) sono fuori dall'ambito di questa specifica, come descritto nella Sezione 7.
1.6. Versione TLS
Ogni volta che questa specifica usa Transport Layer Security (TLS), la versione o le versioni appropriate di TLS varieranno nel tempo, in base alla diffusione e alle vulnerabilità di sicurezza note. Al momento della stesura, TLS versione 1.2 [RFC5246] è la versione più recente, ma ha una base di distribuzione molto limitata e potrebbe non essere prontamente disponibile per l'implementazione. TLS versione 1.0 [RFC2246] è la versione più diffusamente distribuita e fornirà la più ampia interoperabilità.
Le implementazioni possono anche supportare ulteriori meccanismi di sicurezza a livello di trasporto che soddisfino i loro requisiti di sicurezza.
1.7. Reindirizzamenti HTTP
Questa specifica fa ampio uso dei reindirizzamenti HTTP, nei quali il client o il server di autorizzazione indirizza lo user-agent del proprietario della risorsa verso un'altra destinazione. Sebbene gli esempi in questa specifica mostrino l'uso del codice di stato HTTP 302, qualsiasi altro metodo disponibile tramite lo user-agent per realizzare questo reindirizzamento è consentito ed è considerato un dettaglio implementativo.
1.8. Interoperabilità
OAuth 2.0 fornisce un ricco framework di autorizzazione con proprietà di sicurezza ben definite. Tuttavia, essendo un framework ricco e altamente estensibile con molti componenti opzionali, questa specifica da sola probabilmente produrrà un'ampia gamma di implementazioni non interoperabili.
Inoltre, questa specifica lascia alcuni componenti richiesti parzialmente o completamente non definiti, per esempio la registrazione del client, le capacità del server di autorizzazione e la scoperta degli endpoint. Senza questi componenti, i client devono essere configurati manualmente e specificamente per un determinato server di autorizzazione e server delle risorse al fine di interoperare.
Questo framework è stato progettato con la chiara aspettativa che lavori futuri definiranno profili prescrittivi ed estensioni necessari per ottenere piena interoperabilità su scala Web.
1.9. Convenzioni notazionali
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questa specifica devono essere interpretate come descritto in [RFC2119].
Questa specifica usa la notazione Augmented Backus-Naur Form (ABNF) di [RFC5234]. Inoltre, la regola URI-reference è inclusa da "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986].
Alcuni termini relativi alla sicurezza devono essere intesi nel senso definito in [RFC4949]. Questi termini includono, tra gli altri, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate" e "verify".
Salvo diversa indicazione, tutti i nomi e i valori dei parametri del protocollo distinguono tra maiuscole e minuscole.