OAuth 2.0 è un framework di autorizzazione che consente agli utenti di condividere in modo sicuro i propri dati tra diverse applicazioni.
Rappresenta uno standard di settore che affronta le problematiche di sicurezza delle interfacce di programmazione associate alla condivisione delle credenziali degli utenti, fornendo processi di autorizzazione semplici e ben definiti per applicazioni web, dispositivi mobili, sistemi desktop e oggetti connessi.
In questo articolo, esamineremo l’evoluzione di OAuth 2.0, per poi analizzare nel dettaglio il suo funzionamento.
Successivamente, approfondiremo vantaggi, criticità e prassi ottimali per l’utilizzo di OAuth 2.0, evidenziandone le caratteristiche principali.

Storia e contesto di OAuth 2.0
Gli utenti interagiscono quotidianamente con molteplici applicazioni, condividendo dati tra ognuna di esse.
Ad esempio, un utente potrebbe voler consentire a una nuova applicazione di accedere ai propri dati memorizzati in un altro servizio per ottenere un’esperienza personalizzata.
Questa integrazione oggi offre numerosi vantaggi, ma storicamente presentava diverse criticità in termini di sicurezza:
Esposizione delle credenziali dell’utente
prima dell’avvento di OAuth, l’utente doveva fornire le proprie credenziali direttamente alle applicazioni di terze parti, introducendo significativi rischi per la sicurezza. Le applicazioni potevano potenzialmente memorizzare tali credenziali in modo non sicuro, rendendole vulnerabili in caso di violazione dei dati.
Gestione dell’ambito di accesso
non esisteva un meccanismo efficace per limitare l’accesso delle applicazioni ai soli dati necessari.
Un’applicazione di terze parti poteva potenzialmente accedere a informazioni che l’utente non intendeva condividere, come dati personali sensibili o metadati non pertinenti.
Impossibilità di revoca selettiva
gli utenti non potevano facilmente revocare l’accesso a singole applicazioni senza modificare le proprie credenziali principali, il che avrebbe influenzato tutte le applicazioni precedentemente autorizzate.
OAuth, nato come iniziativa comunitaria nel 2007 e attualmente gestito dall’Internet Engineering Task Force (IETF), ha risolto queste problematiche introducendo un meccanismo di autorizzazione basato su token. Questo approccio innovativo elimina la necessità di condividere le credenziali effettive, permette di definire ambiti specifici di accesso e consente agli utenti di gestire e revocare le autorizzazioni in modo granulare, garantendo un controllo più preciso sulla propria privacy e sui propri dati.
Funzionamento dettagliato di OAuth 2.0
Il protocollo OAuth 2.0 si basa su quattro ruoli fondamentali, ciascuno con responsabilità specifiche nel processo di autorizzazione:
- Proprietario della risorsa: l’utente finale che autorizza l’accesso ai propri dati protetti.
- Cliente: l’applicazione che richiede l’accesso ai dati del proprietario della risorsa. Quando ottiene l’autorizzazione, riceve un token di accesso utilizzabile per richiedere le risorse nell’ambito concesso.
- Server di autorizzazione: l’intermediario che gestisce l’autenticazione del proprietario della risorsa e emette i token di accesso al cliente dopo una corretta autorizzazione.
- Server delle risorse: il sistema che custodisce i dati protetti ed è responsabile di accettare e rispondere alle richieste di accesso mediante la validazione dei token.
Il processo di autorizzazione si articola in diverse fasi.

Quando un’applicazione necessita di accedere ai dati di un utente conservati su un altro servizio, si avvia un processo di autorizzazione articolato ma ben definito. Tutto inizia nel momento in cui l’utente manifesta l’intenzione di collegare i due servizi, magari cliccando su un pulsante del tipo “Accedi con…” o “Connetti a…“.
A questo punto, l’applicazione prepara una richiesta di autorizzazione accuratamente strutturata e indirizza l’utente verso il servizio che detiene i dati desiderati.
Una volta reindirizzato, l’utente si trova di fronte alla familiare schermata di accesso del servizio che ospita i suoi dati. Qui può inserire le proprie credenziali in tutta sicurezza, sapendo che queste informazioni sensibili non verranno mai condivise con l’applicazione richiedente.
Dopo aver effettuato l’accesso, all’utente viene presentata una schermata che descrive chiaramente quali dati l’applicazione vorrebbe utilizzare e quali azioni vorrebbe compiere. È in questo momento che l’utente ha il pieno controllo della situazione e può decidere consapevolmente se concedere o negare l’autorizzazione richiesta.
Se l’utente decide di procedere e autorizza l’accesso, il servizio genera un codice speciale, una sorta di “biglietto” temporaneo che l’applicazione potrà utilizzare nel passaggio successivo. Questo codice viene inviato all’applicazione attraverso un reindirizzamento sicuro dell’utente.
L’applicazione, ora in possesso di questo codice temporaneo, lo utilizza immediatamente per richiedere un “token di accesso” più duraturo e utilizzabile.
Questa richiesta avviene direttamente tra l’applicazione e il servizio che detiene i dati, senza coinvolgere ulteriormente l’utente. Il token di accesso che viene fornito in risposta è come una chiave speciale che l’applicazione può utilizzare per accedere ai dati autorizzati.
Da questo momento in poi, ogni volta che l’applicazione ha bisogno di accedere ai dati dell’utente, presenta questo token di accesso al servizio che li custodisce. Il servizio, prima di fornire qualsiasi dato, verifica accuratamente la validità del token e controlla che corrisponda esattamente alle autorizzazioni concesse dall’utente. Solo dopo queste verifiche, il servizio fornisce i dati richiesti all’applicazione.
Questo processo, apparentemente complesso, è stato progettato per garantire la massima sicurezza e il pieno controllo da parte dell’utente, assicurando al contempo un’esperienza fluida e trasparente per tutti i soggetti coinvolti.
Sfide di sicurezza nell’implementazione
Nonostante la sua diffusa adozione, l’implementazione di OAuth 2.0 presenta diverse sfide in termini di sicurezza che richiedono particolare attenzione:
Gestione dei token di accesso
I token di accesso rappresentano le “chiavi del regno” e devono essere gestiti con estrema cautela.
È fondamentale:
- Utilizzare database su reti interne con rigorosi controlli di accesso- Implementare la crittografia per i token memorizzati
- Utilizzare cookie con attributi HTTP-only e Secure quando necessario. L’attributo HTTP-only impedisce l’accesso al token tramite JavaScript, proteggendo così da potenziali attacchi di cross-site scripting, mentre l’attributo Secure garantisce che il cookie venga trasmesso solo su connessioni HTTPS crittografate.
- Implementare meccanismi di scadenza appropriati per limitare la finestra di vulnerabilità.
Validazione dell’URI di reindirizzamento
La manipolazione degli URL di reindirizzamento rappresenta un vettore di attacco significativo. Per mitigare questo rischio:
- Implementare una rigorosa validazione degli URI rispetto a una lista di URL approvati
- Evitare l’uso di caratteri jolly o reindirizzamenti dinamici
- Verificare che gli URL corrispondano esattamente a quelli registrati
Protezione da attacchi di tipo Cross-Site Request Forgery
Gli attacchi CSRF possono compromettere il processo di autorizzazione.
È essenziale:
- Generare un token “state” unico per ogni richiesta di autorizzazione. Questo parametro funziona come un sigillo di sicurezza su un documento: se viene manomesso o manca, sappiamo che qualcosa non va. Per ogni richiesta di autorizzazione, l’applicazione cliente dovrebbe generare un valore “state” univoco e imprevedibile, memorizzarlo e poi verificare che il valore restituito corrisponda a quello originale.
- Validare questo token al ritorno dell’utente all’URL di callback
- Implementare ulteriori misure di sicurezza come token anti-CSRF nei form
Prevenzione di accessi non autorizzati tramite riferimenti diretti
Per prevenire accessi non autorizzati:
- Implementare rigorosi controlli di accesso a livello di risorsa
- Verificare che il token di accesso corrisponda al legittimo proprietario
- Utilizzare identificatori di risorse non prevedibili
Validazione degli ambiti di accesso
Una validazione insufficiente degli ambiti può portare a accessi non autorizzati. È necessario:
- Implementare il principio del minimo privilegio
- Documentare chiaramente gli ambiti disponibili e il loro utilizzo
Gestione del flusso di concessione
Il flusso di concessione implicita presenta rischi importanti. Si raccomanda:
- Utilizzare il flusso del codice di autorizzazione con PKCE
- Implementare timeout appropriati per i codici di autorizzazione
- Considerare l’utilizzo di token di aggiornamento per le applicazioni appropriate
L’implementazione attenta di queste misure di sicurezza consente di ridurre significativamente i rischi associati all’utilizzo di OAuth 2.0, garantendo una protezione efficace per le risorse degli utenti e l’integrità delle applicazioni. È fondamentale mantenersi aggiornati sulle migliori pratiche di sicurezza e sulle nuove vulnerabilità che potrebbero emergere.



