OAuth 2.0: cos’è e come funziona lo standard “aperto” per l’autenticazione sicura online

Il framework di autenticazione OAuth 2.0 è uno standard aperto che consente ad un utente di concedere ad un sito Web o ad un’applicazione di terze parti l’accesso alle proprie risorse protette, senza necessariamente rivelare a terzi le proprie credenziali o addirittura l’identità.

Pensiamo, ad esempio, a quando per accedere a un sito web ci viene offerta una o più opportunità di accesso, utilizzando l’esito dell’autenticazione su uno dei siti web o servizi visualizzati. Selezioniamo uno di questi e ci autentichiamo con le nostre credenziali per quel sito/servizio. Di conseguenza, il primo sito riceverà dal sito ove ci siamo appena autenticati, l’autorizzazione per il nostro accesso. Questo è OAuth.

Che cos’è OAuth 2.0

OAuth 2.0 rappresenta un elemento essenziale per la sicurezza e la privacy nell’odierno ecosistema digitale. Il suo design robusto e flessibile lo rende una soluzione ideale per concedere l’accesso delegato a risorse online, garantendo al contempo la protezione dei dati degli utenti e il controllo granulare dell’autorizzazione.

In un tipico scenario OAuth 2.0, l’utente avvia il processo cliccando su un pulsante o un link all’interno dell’applicazione client. Questo reindirizza l’utente al server di autorizzazione, dove viene visualizzata una richiesta di autorizzazione che specifica le risorse a cui l’applicazione client desidera accedere.

Se l’utente concede l’autorizzazione, il server di autorizzazione verifica l’identità dell’utente e genera un token di accesso. Il token viene quindi inviato in modo sicuro all’applicazione client, che può utilizzarlo per accedere alle risorse autorizzate sul server web.

Vantaggi di OAuth 2.0

OAuth 2.0 offre numerosi vantaggi rispetto ai tradizionali meccanismi di autenticazione e autorizzazione:

• Sicurezza migliorata: Elimina la necessità per l’utente di condividere le proprie credenziali di accesso con applicazioni di terze parti, riducendo il rischio di furti d’identità e accessi non autorizzati.

• Maggiore controllo dell’utente: L’utente concede l’autorizzazione in modo granulare, specificando le risorse a cui l’applicazione client può accedere.

• Flessibilità e adattabilità: Adatto a un’ampia gamma di scenari di applicazione, dalle applicazioni web native alle applicazioni mobili e ai dispositivi IoT.

• Standardizzazione aperta: Protocollo aperto e ampiamente adottato, che favorisce l’interoperabilità tra diverse piattaforme e servizi.

OAuth 2.0: come funziona l’access token

Tutto ciò è possibile perché OAuth 2.0 è un protocollo di autenticazione basato sui token (token-based authentication). Il token è una stringa, firmata da un server per le verifiche di integrità, che può contenere molte informazioni sull’utente, quali autorizzazioni, gruppi di appartenenza ed indicatori di tempo.

L’utente mantiene l’accesso finché il token rimane valido. Un tipico token di accesso (access token) contiene tre parti distinte, che lavorando insieme, verificano il diritto dell’utente di accedere ad una risorsa. I tre elementi chiave sono:

1. Header (intestazione): i dati sul tipo di token e l’algoritmo utilizzato per realizzarlo sono inclusi qui.
2. Payload (carico utile): le informazioni sull’utente, comprese le autorizzazioni e le scadenze, sono incluse qui. Questa parte è anche detta sezione delle richieste (claims section).
3. Signature (firma): i dati di verifica, affinché il destinatario possa garantire l’autenticità del token, sono inclusi qui. Questa firma è in genere di tipo hash, perciò è difficile da forzare e riprodurre.

Quanti tipi di token esistono

Il payload è fondamentale per il buon risultato del token d’accesso. Non importa quanti dati sono inclusi, i token d’accesso sono definiti da codifiche che tendono a crearli molto compatti. Possono contenere credenziali per l’accesso ad applicazioni multiple, tutto con un solo token, ad esempio, il token di accesso alle applicazioni Google, oppure possono presentarsi in modi diversi. Ad esempio, Facebook usa quattro diversi tipi, a seconda dell’uso:

1. token d’accesso utente: è necessario per concedere le autorizzazioni ad interagire con i dati dell’utente. Generalmente, preventivamente è richiesto il consenso dell’utente tramite un opportuno form;
2. token d’accesso dell’app: è necessario per concedere le autorizzazioni ad interagire con i dati dell’app. Per la generazione viene utilizzata una password predefinita tra app e Facebook;
3. token d’accesso della pagina: è necessario per concedere le autorizzazioni ad interagire con i dati della pagina. Per ottenere questo token, è necessario avere prima ottenuto un token d’accesso utente;
4. token client: è un identificativo che si può incorporare nel codice binario delle app e serve per l’identificazione della particolare app.

L’uso dei token conferisce grande flessibilità ma soprattutto riduce la necessità di trasmettere continuamente le credenziali di autenticazione di lungo periodo (complete di dati personali), a favore di permessi di autenticazione temporanei (token).

Flusso di autenticazione di OAuth 2.0

Se consideriamo il flusso di autenticazione secondo il punto di vista dell’utente, abbiamo una serie ben precisa di passaggi per accedere al server delle risorse dal proprio browser:

1. Accesso: utilizziamo il nome utente ed una password (credenziali) per dimostrare la nostra identità.
2. Verifica: il server autentica le credenziali ricevute ed emette il token d’accesso.
3. Immagazzinamento: il token viene inviato al browser per essere conservato localmente.
4. Comunicazione: ogni volta che si accede a qualcosa di nuovo sul lato server, il token viene sempre verificato nuovamente.
5. Cancellazione: al termine della sessione, il token viene eliminato.

Se consideriamo il modello tecnico/funzionale su cui si basa il processo di autenticazione nel suo complesso, dobbiamo descrivere l’interazione di quattro tipi di ruoli:

1. Client: è l’applicazione che richiede l’accesso ad una risorsa protetta per conto del proprietario della risorsa. L’applicazione può essere quella dell’End-User oppure del Service Provider (talvolta detto anche relying party).
2. Resource Owner: è l’entità in grado di concedere l’accesso ad una risorsa protetta. Quando l’entità è un individuo allora viene definito utente finale (end-user).
3. Resource Server: è il server che ospita le risorse protette, capace di accettare e rispondere alla richieste usando il token di accesso. Tipicamente è gestito da un Service Provider.
4. Authorization Server: è il server che autentica il Resource Owner ed emette i token di accesso dopo aver ottenuto la giusta autorizzazione. Tipicamente è gestito da un Identity Provider.

ed inoltre fa uso del termine User Agent per indicare il browser usato dall’utente per fare la richiesta di accesso ad una risorsa online. Il protocollo OAuth 2.0 di autorizzazione all’accesso alle risorse, è posizionato entro un’architettura più ampia di identità federata, descritta dal relativo standard, ad esempio OpenID Connect, che attiva il processo di identificazione e autenticazione dell’utente.

Schema generale di autorizzazione di OAuth 2.0

Il flusso generale di funzionamento del protocollo di autorizzazione OAuth 2.0 è sintetizzato dai seguenti sei passi, descrivendo le interazioni tra i quattro ruoli:

1. Il Client invia una richiesta di autorizzazione al Resource Owner. Può avvenire direttamente o per tramite dell’Authorization Server che agisce come intermediario.
2. Il Client riceve una concessione di autorizzazione authorization grant, che rappresenta una credenziale con l’autorizzazione del Resource Owner e può essere espressa in uno dei quattro modi previsti, purché supportati dall’Authorization Server.
3. Il Client richiede un token di accesso autenticandosi sull’Authorization Server, presentando la concessione di autorizzazione.
4. L’Authorization Server autentica il Client, convalida la concessione di autorizzazione e, se valido, emette un token di accesso.
5. Il Client richiede la risorsa protetta dal server delle risorse, presentando il token di accesso.
6. Il Resource Server convalida il token di accesso e, se valido, soddisfa la richiesta.

Il protocollo OAuth 2.0 prevede i seguenti flussi per i quattro tipi di concessione dell’autorizzazione (grant type):

1. Codice di autorizzazione (Authorization Code): il codice di autorizzazione viene ottenuto utilizzando un Authorization Server come intermediario tra il Client e il Resource Owner. Il Client indirizza direttamente il Resource Owner sull’Authorization Server per autenticarsi, ed in questo modo il Resource Owner non condivide le sue credenziali con Client.
2. Implicito (Implicit): è un flusso di codice di autorizzazione semplificato ed ottimizzato per i Client su browser che utilizzano un linguaggio di scripting come JavaScript. Viene emesso il token di accesso direttamente senza scambio della concessione di autorizzazione.
3. Credenziali della password del Resource Owner (Resource Owner Password Credentials): le credenziali di sicurezza del Resource Owner (cioè utente e password) sono usate come concessione di autorizzazione per ottenere il token di accesso.
4. Credenziali client (Client Credentials): le credenziali del Client sono utilizzate come concessione di autorizzazione, tipicamente quando il Client è anche Resource Owner. Può essere utilizzato per la comunicazione machine-to-machine.

Il token di accesso è dotato di scadenza. Per gestire la scadenza senza richiedere l’intervento dell’utente può essere emesso anche un token di aggiornamento (refresh token). Questi sono credenziali utilizzate per ottenere un nuovo token di accesso, quando il token di accesso attuale diventa non valido, o scade, o per ottenere ulteriori token di accesso con ambito identico o ristretto (i token di accesso possono avere una durata più breve e meno autorizzazioni rispetto a quelle autorizzate dal Resource Owner).

Le Native Applications gestite da OAuth 2.0

Le Native Applications sono programmi eseguibili scritti per uno specifico sistema operativo, spesso in contrasto con le Web Applications che sono memorizzate su un server ed eseguite nel browser.

Ogni browser interpreta i codici JavaScript e HTML nella Web App indipendentemente dalla piattaforma in cui il browser viene eseguito, rendendo così universali le applicazioni delle Web App.

Le Native App funzionano sempre più velocemente della loro controparte Web, perché non vi è alcun processo di traduzione tra il codice sorgente della pagina web ed il linguaggio macchina del computer. Ciò nonostante, a seconda della quantità di elaborazione che si svolge all’interno dell’applicazione, gli utenti potrebbero notare poca differenza di velocità.

Anche le Native Applications sono gestite dal protocollo OAuth 2.0, sono definite come Client App che vengono installate ed eseguite su dispositivi usati direttamente dal Resource Owner (User). Per questo processo di autorizzazione si utilizzano risorse http che interagiscono tramite lo user-agent con due endpoint (interfaccia) dell’Authorization Server:

1. Authorization Endpoint – utilizzato dal Client per ottenere la concessione di autorizzazione dal Resource Owner, tramite il reindirizzamento effettuato dallo User Agent (browser).
2. Token Endpoint – utilizzato dal Client per scambiare la concessione di autorizzazione per un token di accesso ed eventualmente un refresh token.

Il modello di funzionamento dell’autorizzazione per applicazioni native è sintetizzato dai seguenti sei passi:

1. La Client App apre un browser tab con la richiesta di autorizzazione.
2. L’Authorization Endpoint riceve la richiesta di autorizzazione, autentica l’utente e ottiene l’autorizzazione. Autenticare l’utente potrebbe richiedere il coinvolgimento di altri sistemi di autenticazione.
3. L’Authorization Server rilascia un codice di autorizzazione reindirizzandolo sull’URI (Uniform Resource Identifier) dell’app.
4. La Client App riceve il codice di autorizzazione.
5. La Client App esibisce il codice di autorizzazione al Token Endpoint.
6. Il Token Endpoint convalida il codice di autorizzazione ed emette i token richiesti.

Adottando gli stessi metodi utilizzati da OAuth sul Web, i vantaggi come l’usabilità del single sign-on o la sicurezza di un contesto di autenticazione separato sono condivisi anche nel contesto dell’applicazione nativa. Il riutilizzo dello stesso approccio riduce anche la complessità dell’implementazione e aumenta l’interoperabilità basandosi su flussi web regolati da standard che non sono specifici per una particolare piattaforma.

Conclusioni

La versione 2.0 di OAuth è nata nel 2012 e continua nel suo processo di miglioramento, aggiungendo o eliminando funzionalità, per seguire l’evoluzione del web e dei dispositivi mobile.

Per includere dispositivi privi di browser o di tastiera (es. Smart TV, streaming video encoder) è stato aggiunto un nuovo set di specifiche, che aggiunge una quinta classe di concessioni di autorizzazione, detta “Device Grant”, ma nello stesso tempo la prima classe è stata migliorata generalizzandola ed ha reso obsolete le classi Implicit e Password portando il nuovo totale delle classi a tre.

Probabilmente, con queste ed altre innovazioni non citate, siamo pronti per riassumere il tutto in una nuova versione. In attesa di una major version 3.0, al momento è ufficialmente riconosciuta la 2.1 come draft per incorporare le best practice aggiunte all’attuale versione base OAuth 2.0.