OAuth2: autenticazione sicura online

• OAuth 2.0: lo standard sicuro per l’autenticazione online 
• Cos’è OAuth 2.0 e come funziona? 
• Flusso di autorizzazione in OAuth 2.0 
• Differenze tra OAuth 1.0 e OAuth 2.0 
• Access token e refresh token in OAuth 2.0 
• Grant type in OAuth 2.0: i diversi flussi di autenticazione 
• OAuth 2.0 per applicazioni mative 

---

OAuth 2.0: lo standard sicuro per l’autenticazione online 

L’autenticazione e l’autorizzazione online sono fondamentali per proteggere i dati e gestire gli accessi. OAuth 2.0 è uno standard aperto che consente agli utenti di ottenere l’accesso a servizi online senza dover condividere direttamente le proprie credenziali.

Questo protocollo è alla base di soluzioni come il Single Sign-On (SSO) ed è ampiamente utilizzato da piattaforme come Google, Facebook e Amazon. 

In questo articolo esploreremo il funzionamento di OAuth 2.0, i vantaggi rispetto a OAuth 1.0, il ruolo di access token e refresh token, e i diversi grant type utilizzati per l’autenticazione. 

Cos’è OAuth 2.0 e come funziona? 

OAuth 2.0: funzionamento dettagliato con esempi e codice 

OAuth 2.0 è un protocollo di autorizzazione che permette alle applicazioni di accedere ai dati degli utenti senza esporre direttamente le loro credenziali.

Invece di utilizzare username e password per ogni richiesta, OAuth 2.0 richiede un token di accesso, un codice temporaneo che concede i permessi necessari per interagire con una risorsa protetta. 

I principali attori in OAuth 2.0 

Nel flusso di autorizzazione OAuth 2.0, quattro entità principali interagiscono tra loro: 

• Client
  L’applicazione che richiede l’accesso a una risorsa. 

• Resource owner
  L’utente che possiede i dati e concede l’autorizzazione. 

• Resource server
  Il server che ospita la risorsa protetta e risponde alle richieste se l’access token è valido. 

• Authorization server
  Il server che autentica il resource owner ed emette un access token al client. 

Esempio pratico
Immaginiamo un’applicazione chiamata PhotoShare che permette agli utenti di modificare e pubblicare foto direttamente dal proprio account Google Drive. 

• PhotoShare è il client che deve ottenere l’accesso alle immagini archiviate su Google Drive (il resource server). 

• L’utente (resource owner) accede a Google (authorization server) per autorizzare l’accesso dell’app alle proprie immagini. 

• Una volta autorizzato, Google rilascia un access token che permette a PhotoShare di interagire con Google Drive senza richiedere le credenziali dell’utente ogni volta. 

Flusso di autorizzazione in OAuth 2.0 

Il processo di autorizzazione segue questi passaggi fondamentali: 

Il client reindirizza l’utente al server di autorizzazione 

Quando l’utente accede all’app, il client lo reindirizza all’authorization server, includendo nella richiesta i seguenti parametri: 

• Client_id
  L’ID dell’applicazione registrata. 

• Response_type
  Il tipo di risposta richiesta (in genere code per il flusso di autorizzazione). 

• Redirect_uri
  L’URL a cui l’utente verrà reindirizzato dopo l’autorizzazione. 

• Scope
  Le autorizzazioni richieste (ad esempio, read o write). 

Esempio di richiesta GET: 

http 

GET https://accounts.google.com/o/oauth2/auth? 

    response_type=code& 

    client_id=CLIENT_ID& 

    redirect_uri=https://photoshare.com/callback& 

    scope=https://www.googleapis.com/auth/drive.readonly& 

    state=xyz

L’utente autentica la richiesta e concede il permesso 

L’utente viene indirizzato a una pagina di login su Google e, una volta autenticato, vedrà una schermata in cui concede o nega il permesso all’app PhotoShare di accedere alle sue immagini. 

Se l’utente accetta, l’authorization server genera un authorization code e lo invia al client. 

Esempio di risposta: 

http 

HTTP/1.1 302 Found 

Location: https://photoshare.com/callback?code=AUTHORIZATION_CODE&state=xyz

Il client scambia il code per un access token 

A questo punto, il client deve scambiare il code ricevuto con un access token inviando una richiesta POST al token endpoint dell’authorization server. 

Esempio di richiesta POST: 

http 

POST https://oauth2.googleapis.com/token 

Content-Type: application/x-www-form-urlencoded 

client_id=CLIENT_ID& 

client_secret=CLIENT_SECRET& 

grant_type=authorization_code& 

code=AUTHORIZATION_CODE& 

redirect_uri=https://photoshare.com/callback

Se tutto è corretto, il server di autorizzazione risponde con un access token e, eventualmente, un refresh token per prolungare l’accesso senza dover ripetere il login. 

Esempio di risposta: 

json 

{ 

  "access_token": "ya29.a0AfH6SM...", 

  "expires_in": 3600, 

  "refresh_token": "1//09X...", 

  "scope": "https://www.googleapis.com/auth/drive.readonly", 

  "token_type": "Bearer" 

}

Il client usa l’access token per accedere alla risorsa protetta 

Ora che il client ha ottenuto un access token, può utilizzarlo per accedere alla risorsa protetta su Google Drive. 

Per farlo, deve includere il token nell’Authorization Header delle richieste API: 

http 

GET https://www.googleapis.com/drive/v3/files 

Authorization: Bearer ya29.a0AfH6SM...

Se il token è valido, il resource server (Google Drive) risponde con i dati richiesti. 

Esempio di risposta: 

json 

{ 

  "files": [ 

    { 

      "id": "1a2b3c", 

      "name": "vacanza.jpg", 

      "mimeType": "image/jpeg" 

    } 

  ] 

}

Se il token è scaduto o non valido, il server risponderà con un errore 401 Unauthorized, richiedendo un nuovo access token. 

Quando il token scade: uso del refresh token 

Poiché gli access token hanno una durata limitata (es. 1 ora), il client può usare il refresh token per ottenerne uno nuovo senza richiedere l’autorizzazione all’utente. 

Richiesta di un nuovo token con il refresh token: 

http 

POST https://oauth2.googleapis.com/token 

Content-Type: application/x-www-form-urlencoded 

client_id=CLIENT_ID& 

client_secret=CLIENT_SECRET& 

grant_type=refresh_token& 

refresh_token=1//09X... 

Risposta con un nuovo access token: 

json 

{ 

  "access_token": "ya29.a0AfH6SM...NEW", 

  "expires_in": 3600, 

  "token_type": "Bearer" 

}

Conclusioni 

L’utilizzo di OAuth 2.0 migliora la sicurezza perché evita la condivisione delle credenziali e permette all’utente di controllare quali applicazioni possono accedere ai propri dati. Inoltre, grazie ai refresh token, il sistema può mantenere le sessioni attive senza richiedere ripetuti login. 

Questo protocollo è ampiamente utilizzato per servizi come: 

• Google Sign-In (per accedere con il proprio account Google);

• Facebook Login (autenticazione su siti di terze parti);

• API di servizi cloud (es. Dropbox, GitHub, Microsoft 365). 

Esempio di implementazione in Python (usando requests): 

python 

import requests 

TOKEN = "ya29.a0AfH6SM..." 

headers = {"Authorization": f"Bearer {TOKEN}"} 

response = requests.get("https://www.googleapis.com/drive/v3/files", headers=headers) 

if response.status_code == 200: 

    print("Risultati:", response.json()) 

else: 

    print("Errore:", response.status_code, response.text)

Con questa configurazione, OAuth 2.0 diventa un meccanismo sicuro ed efficiente per gestire l’autenticazione e l’accesso alle risorse protette online. 

Differenze tra OAuth 1.0 e OAuth 2.0 

Prima di OAuth 2.0, l’autenticazione delegata avveniva tramite OAuth 1.0, che presentava limiti significativi.

OAuth 2.0 ha introdotto miglioramenti importanti: 

• Semplificazione
  Non richiede firme crittografiche complesse, rendendo più semplice l’implementazione. 

• Supporto per applicazioni mobile
  Offre metodi più efficienti per applicazioni native. 

• Flussi di autorizzazione flessibili
  Consente diverse modalità di concessione (grant type) in base al contesto. 

• Gestione sicura dei token
  Introduce il refresh token per mantenere l’accesso senza dover reinserire le credenziali. 

Queste caratteristiche hanno reso OAuth 2.0 lo standard preferito per la sicurezza online. 

Access token e refresh token in OAuth 2.0 

OAuth 2.0 si basa su token di accesso e token di aggiornamento per autenticare gli utenti e gestire in modo sicuro la durata delle sessioni.

Access token 

L’access token è una credenziale temporanea che concede l’accesso a una risorsa protetta. Ha tre componenti principali: 

• Header
  Contiene informazioni sul tipo di token e l’algoritmo di firma. 

• Payload
  Include dati dell’utente, permessi e scadenza. 

• Signature
  Garantisce l’integrità del token e impedisce manomissioni. 

L’access token ha una durata limitata, riducendo il rischio di compromissione. 

Refresh token 

Un refresh token consente di ottenere un nuovo access token senza dover autenticare nuovamente l’utente. Questo meccanismo migliora la sicurezza e l’esperienza utente, mantenendo le sessioni attive senza necessità di reinserire le credenziali. 

Grant type in OAuth 2.0: i diversi flussi di autenticazione 

OAuth 2.0 supporta diversi grant type, ovvero flussi di autorizzazione progettati per adattarsi a vari scenari di autenticazione e livelli di sicurezza. La scelta del grant type dipende dal tipo di applicazione, dalla sicurezza richiesta e dall’esperienza utente desiderata. 

Di seguito, analizziamo i principali grant type, illustrandone il funzionamento con esempi e codice. 

Authorization Code Grant (il metodo più sicuro per web app e server) 

L’Authorization Code Grant è il flusso più utilizzato e sicuro, ideale per applicazioni web e server backend. Questo metodo prevede l’uso di un codice di autorizzazione intermedio che deve essere scambiato per un access token, evitando di esporre il token nel browser. 

Come funziona 

• il client reindirizza l’utente al server di autorizzazione per effettuare l’accesso; 

• dopo l’autenticazione, il server di autorizzazione invia un authorization code al client;

• il client scambia il codice di autorizzazione con un access token tramite una richiesta backend, evitando così l’esposizione del token nel browser. 

Esempio di richiesta di autorizzazione (reindirizzamento dell’utente) 

http 

GET https://accounts.google.com/o/oauth2/auth? 

    response_type=code& 

    client_id=TUO_CLIENT_ID& 

    redirect_uri=https://tuoapp.com/callback& 

    scope=read_profile& 

    state=xyz 

Esempio di Scambio del Codice per un Access Token (Server-Side) 

http 

POST https://oauth2.googleapis.com/token 

Content-Type: application/x-www-form-urlencoded 

client_id=TUO_CLIENT_ID& 

client_secret=TUO_CLIENT_SECRET& 

grant_type=authorization_code& 

code=CODICE_AUTORIZZAZIONE& 

redirect_uri=https://tuoapp.com/callback

Quando utilizzarlo 

• Perfetto per app web e servizi backend;
• Maggiore sicurezza, poiché l’access token non viene esposto nel browser;
• Supporta refresh token per sessioni prolungate. 

Implicit Grant (deprecato, usato per applicazioni single-page) 

L’Implicit Grant è una versione semplificata dell’Authorization Code Grant, usata per Single-Page Applications (SPA). Invece di scambiare un authorization code, il client riceve direttamente l’access token nella risposta. 

Come funziona 

• il client reindirizza l’utente al server di autorizzazione;

• dopo l’autenticazione, il server di autorizzazione restituisce immediatamente un access token nella URL. 

Esempio di richiesta di autorizzazione 

http 

GET https://accounts.google.com/o/oauth2/auth? 

    response_type=token& 

    client_id=TUO_CLIENT_ID& 

    redirect_uri=https://tuoapp.com/callback& 

    scope=read_profile& 

    state=xyz

Questo metodo è meno sicuro, poiché il token è visibile nella URL e può essere intercettato. 

Quando utilizzarlo 

• non consigliato per motivi di sicurezza;
• meglio utilizzare Authorization Code Grant con PKCE per le SPA. 

Password Grant (deprecato, solo per applicazioni di fiducia) 

Il Password Grant consente agli utenti di inserire direttamente username e password nell’applicazione, che poi li scambia con un access token. Questo metodo è meno sicuro poiché l’app deve gestire direttamente le credenziali dell’utente. 

Come funziona 

• l’utente inserisce username e password nell’applicazione;

• il client invia le credenziali al server di autorizzazione per ottenere un access token. 

Esempio di richiesta di access token 

http 

POST https://oauth2.googleapis.com/token 

Content-Type: application/x-www-form-urlencoded 

client_id=TUO_CLIENT_ID& 

client_secret=TUO_CLIENT_SECRET& 

grant_type=password& 

username=utente@example.com& 

password=TUA_PASSWORD

Rischio elevato: l’app deve gestire direttamente le credenziali dell’utente. 

Quando utilizzarlo 

• adatto solo per app interne e di fiducia;
• non consigliato per applicazioni pubbliche: usare Authorization Code Grant invece. 

Client Credentials Grant (per comunicazioni Machine-to-Machine) 

Il Client Credentials Grant è utilizzato quando un’applicazione agisce per conto proprio, senza un utente coinvolto. È perfetto per comunicazioni tra server (M2M – Machine-to-Machine). 

Come funziona 

• il client si autentica con il server di autorizzazione utilizzando il proprio client ID e client secret;

• il server di autorizzazione rilascia un access token. 

Esempio di richiesta di access token 

http 

POST https://oauth2.googleapis.com/token 

Content-Type: application/x-www-form-urlencoded 

client_id=TUO_CLIENT_ID& 

client_secret=TUO_CLIENT_SECRET& 

grant_type=client_credentials& 

scope=read_data

Quando utilizzarlo 

• ideale per comunicazioni server-to-server (API, microservizi);
• sicuro, poiché non coinvolge credenziali utente. 

Device Grant (per dispositivi senza tastiera, es. Smart TV) 

Il Device Grant è progettato per dispositivi senza tastiera o browser, come Smart TV, console di gioco e dispositivi IoT. 

Come funziona 

• il client (dispositivo) richiede un authorization code al server di autorizzazione;

• il server di autorizzazione fornisce un codice utente e un URL di verifica;

• l’utente visita l’URL di verifica su un altro dispositivo, inserisce il codice utente e concede l’autorizzazione;

• il dispositivo controlla periodicamente lo stato di autorizzazione e, una volta confermata, ottiene un access token. 

Esempio di richiesta del codice del dispositivo 

http 

POST https://oauth2.googleapis.com/device/code 

Content-Type: application/x-www-form-urlencoded 

client_id=TUO_CLIENT_ID& 

scope=read_profile 

Risposta del Server: 

json 

{ 

  "device_code": "4/Jb34E", 

  "user_code": "A1B2C3", 

  "verification_uri": "https://example.com/device", 

  "expires_in": 1800 

} 

L’utente visita https://example.com/device, inserisce A1B2C3 e completa l’accesso.

Quando utilizzarlo 

• ideale per Smart TV, IoT, console di gioco;
• più sicuro perché l’autenticazione avviene su un dispositivo separato. 

Conclusione: quale Grant type scegliere? 

Grant Type	Sicurezza	Migliore per
Authorization Code	🔒🔒🔒🔒🔒	Web app, backend
Implicit (Deprecato)	🔒🔒⚠️	SPA (Usare PKCE invece)
Password (Deprecato)	🔒⚠️⚠️	App di fiducia
Client Credentials	🔒🔒🔒	API, server-to-server
Device Grant	🔒🔒🔒	Smart TV, console, IoT

Per la maggior parte delle applicazioni moderne, si raccomanda Authorization Code con PKCE per Web e Mobile, mentre Client Credentials è ideale per comunicazioni tra server.  

OAuth 2.0 per applicazioni mative 

Le applicazioni native (mobile e desktop) utilizzano OAuth 2.0 per gestire l’autorizzazione OAuth in modo sicuro. Poiché non possono memorizzare segreti in modo sicuro, si affidano a authorization server esterni per ottenere access token. 

Il processo prevede: 

• l’app apre una pagina web per autenticare l’utente;

• l’utente concede l’autorizzazione;

• il server di autorizzazione rilascia un codice temporaneo;

• l’app scambia il codice con un access token;

• l’access token viene utilizzato per le richieste API. 

Questo approccio garantisce una maggiore sicurezza e migliora l’esperienza utente grazie al Single Sign-On. 

Conclusioni

OAuth 2.0 è essenziale per la sicurezza e la privacy online, consentendo un’autenticazione sicura senza esporre le credenziali dell’utente. Grazie all’uso di access token e refresh token, migliora la protezione dei dati e semplifica l’accesso alle risorse protette. 

Con il continuo sviluppo del protocollo, l’evoluzione di OAuth 2.0 e la futura versione OAuth 3.0 porteranno ulteriori miglioramenti per affrontare le nuove sfide della sicurezza digitale. 

---

Domande e risposte

1. A cosa serve OAuth 2.0?
   OAuth 2.0 serve per l’autenticazione sicura e il controllo degli accessi senza condividere direttamente le credenziali dell’utente. 
2. Qual è la differenza tra OAuth 1.0 e OAuth 2.0?
   OAuth 2.0 è più semplice, supporta più scenari e introduce meccanismi come il refresh token per una gestione sicura degli accessi. 
3. Cos’è un access token?
   Un access token è un codice temporaneo che concede l’accesso a una risorsa protetta senza richiedere la password dell’utente. 
4. Cos’è un refresh token?
   Un refresh token permette di ottenere un nuovo access token senza dover rieffettuare il login.
5. OAuth 2.0 è sicuro?
   Sì, ma la sicurezza dipende dalla corretta implementazione e dalla protezione degli access token. 
6. Qual è il ruolo di un authorization server?
   L’authorization server autentica l’utente ed emette gli access token per consentire l’accesso sicuro alle risorse. 
7. Cos’è il Single Sign-On in OAuth 2.0?
   Il Single Sign-On (SSO) permette di autenticarsi una sola volta e accedere a più servizi senza dover reinserire le credenziali. 
8. OAuth 2.0 è compatibile con le app mobile?
   Sì, supporta le applicazioni native con flussi di autenticazione ottimizzati. 
9. Quali sono i grant type di OAuth 2.0?
   I più comuni sono authorization code, implicit, password, client credentials e device grant.
10. OAuth 2.0 supporta dispositivi senza tastiera?
    Sì, il device grant consente di autenticarsi tramite un altro dispositivo.