1. Introduzione (Introduction)
Nel modello tradizionale di autenticazione client-server, il client (Client) richiede una risorsa protetta sul server autenticandosi con le credenziali del proprietario della risorsa (Resource Owner). Per fornire alle applicazioni di terze parti l'accesso alle risorse ristrette, il proprietario della risorsa deve condividere le proprie credenziali con la terza parte. Questo crea diversi problemi e limitazioni.
OAuth (OAuth) risolve questi problemi introducendo un livello di autorizzazione (Authorization Layer) e separando il ruolo del client da quello del proprietario della risorsa. In OAuth, il client richiede l'accesso alle risorse controllate dal proprietario della risorsa e ospitate dal server delle risorse (Resource Server), e riceve un insieme di credenziali diverso da quello del proprietario della risorsa.
Invece di utilizzare le credenziali del proprietario della risorsa per accedere alle risorse protette, il client ottiene un token di accesso (Access Token) — una stringa che rappresenta uno specifico ambito (Scope), durata e altri attributi di accesso. I token di accesso vengono emessi ai client di terze parti da un server di autorizzazione (Authorization Server) con l'approvazione del proprietario della risorsa. Il client utilizza il token di accesso per accedere alle risorse protette ospitate dal server delle risorse.
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.
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 (End-User).
Server delle risorse (Resource Server)
Il server che ospita le risorse protette, capace di accettare e rispondere alle richieste di risorse protette utilizzando i 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 caratteristica di implementazione particolare (ad esempio, se l'applicazione viene eseguita su un server, un desktop o 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 va oltre l'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ò (MAY) emettere token di accesso accettati da più server delle risorse.
1.2. Flusso del protocollo (Protocol Flow)
Il flusso astratto di OAuth 2.0 mostra le interazioni tra i quattro ruoli e comprende i seguenti passaggi.
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
(A) Il client richiede l'autorizzazione dal proprietario della risorsa.
(B) Il client riceve un'autorizzazione (Authorization Grant).
(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, valida l'autorizzazione ed emette un token di accesso.
(E) Il client richiede la risorsa protetta dal server delle risorse presentando il token di accesso.
(F) Il server delle risorse valida il token di accesso ed elabora la richiesta se è valida.
1.3. Autorizzazione (Authorization Grant)
Un'autorizzazione (Authorization Grant) è una credenziale che rappresenta l'autorizzazione del proprietario della risorsa, utilizzata dal client per ottenere un token di accesso. Questa specifica definisce quattro tipi di autorizzazione (codice di autorizzazione, implicito, credenziali password del proprietario della risorsa e credenziali del client) oltre a un meccanismo di estensione per definire tipi aggiuntivi.
1.3.1. Codice di autorizzazione (Authorization Code)
Il codice di autorizzazione (Authorization Code) viene ottenuto utilizzando il server di autorizzazione come intermediario tra il client e il proprietario della risorsa.
1.3.2. Implicito (Implicit)
L'autorizzazione implicita (Implicit Grant) è una versione semplificata del codice di autorizzazione, ottimizzata per i client implementati in un browser utilizzando un linguaggio di script come JavaScript.
1.3.3. Credenziali password del proprietario della risorsa (Resource Owner Password Credentials)
Le credenziali password del proprietario della risorsa (nome utente e password) possono essere utilizzate direttamente come autorizzazione per ottenere un token di accesso.
1.3.4. Credenziali del client (Client Credentials)
Le credenziali del client (Client Credentials) possono essere utilizzate come autorizzazione quando l'ambito dell'autorizzazione è limitato alle risorse protette sotto il controllo del client.
1.4. Token di accesso (Access Token)
Un token di accesso (Access Token) è una credenziale utilizzata per accedere alle risorse protette. Rappresenta una stringa che caratterizza l'ambito, la durata e altri attributi di accesso specifici autorizzati dal proprietario della risorsa e applicati dal server delle risorse e dal server di autorizzazione.
1.5. Token di aggiornamento (Refresh Token)
Un token di aggiornamento (Refresh Token) è una credenziale utilizzata per ottenere token di accesso. I token di aggiornamento vengono emessi al client dal server di autorizzazione e vengono utilizzati per ottenere un nuovo token di accesso quando il token di accesso corrente diventa non valido o scade.