OAuth 2.0 è il protocollo standard per l'autorizzazione sicura tra sistemi software. Permette a un'applicazione di agire per conto di un utente su un altro servizio senza condividere le credenziali dell'utente. È il meccanismo che consente al chatbot di accedere al calendario, al CRM o ai documenti aziendali in modo sicuro e controllato.
Cos'è OAuth 2.0?
Prima di OAuth, le applicazioni di terze parti che avevano bisogno di accedere ai dati di un utente su un altro servizio richiedevano direttamente username e password. Questo era pericoloso: l'app aveva accesso illimitato all'account, non c'era modo di revocare solo quel accesso senza cambiare la password, e se l'app veniva compromessa, le credenziali erano esposte.
OAuth 2.0 (pubblicato nel 2012, aggiornato con OAuth 2.1 in corso di standardizzazione) risolve questo problema con un approccio basato su token di accesso: invece di condividere le credenziali, l'utente autorizza esplicitamente l'applicazione richiedente ad accedere a risorse specifiche (scopes), e il servizio rilascia un token temporaneo limitato a quegli scopi.
Nel contesto dei chatbot aziendali, OAuth è il meccanismo che consente integrazioni sicure con servizi come Google Workspace (Calendar, Drive, Gmail), Microsoft 365 (Outlook, Teams), Salesforce, HubSpot e altri. Il bot ottiene un token di accesso per operare per conto dell'utente o dell'organizzazione, senza mai vedere le credenziali di login.
Come Funziona il Flusso OAuth 2.0
Step 1: Richiesta di Autorizzazione
L'applicazione (chatbot) reindirizza l'utente all'endpoint di autorizzazione del server OAuth (es. Google, Microsoft) con parametri specifici: client_id dell'applicazione, scope richiesti (es. "calendar.read", "crm.contacts.write"), redirect_uri dove tornare dopo, e un valore casuale "state" per prevenire CSRF.
Step 2: Autenticazione e Consenso Utente
L'utente vede la schermata di login del servizio (Google, Microsoft). Dopo il login, vede la schermata di consenso che mostra chiaramente quali permessi l'applicazione sta richiedendo (es. "L'app XYZ vuole accedere in lettura al tuo Google Calendar"). L'utente può approvare o rifiutare. Se approva, il server reindirizza al redirect_uri con un "authorization code" temporaneo (valido 1-5 minuti).
Step 3: Scambio Code → Token
Il backend dell'applicazione riceve l'authorization code e lo scambia con il server OAuth per ottenere i token effettivi. Questa chiamata avviene server-to-server (mai nel browser) e include il client_secret. Il server restituisce:
- Access Token: usato per chiamare le API protette (scade in 1 ora tipicamente)
- Refresh Token: usato per ottenere nuovi access token senza re-autenticare l'utente (lunga durata)
- ID Token (OpenID Connect): informazioni identità utente in formato JWT
Step 4: Chiamate API con Access Token
L'applicazione usa l'access token nell'header Authorization per chiamare le API del servizio. Il server verifica la validità del token e restituisce solo i dati coperti dagli scopes autorizzati. Quando il token scade, l'applicazione usa il refresh token per ottenerne uno nuovo automaticamente, senza disturbare l'utente.
OAuth vs API Key: Quando Usare Cosa
Usa OAuth quando...
- Hai bisogno di agire per conto di utenti specifici
- Il servizio target richiede OAuth (Google, Microsoft, Salesforce)
- Servono permessi granulari e revocabili per ogni utente
- L'integrazione deve rispettare i permessi dell'utente sul servizio target
- Vuoi evitare la responsabilità di gestire credenziali altrui
Usa API Key quando...
- L'integrazione è machine-to-machine (nessun utente coinvolto)
- Hai bisogno di accesso a dati dell'intera organizzazione (non di singoli utenti)
- Il servizio non supporta OAuth e offre solo API key
- La semplicità è prioritaria e il rischio di sicurezza è accettabile
- Prototipo o integrazione interna a basso rischio
Scopes OAuth: Permessi Granulari
Cos'è uno Scope?
Gli scopes OAuth definiscono esattamente quali operazioni e dati l'applicazione è autorizzata a usare. Seguono il principio del minimo privilegio: richiedi solo i permessi strettamente necessari. L'utente vede esattamente cosa stai richiedendo nella schermata di consenso. Più scopes richiedi, più è probabile che l'utente rifiuti.
Google Scopes:
- calendar.readonly (solo lettura)
- calendar.events (lettura e scrittura)
- gmail.readonly (email in lettura)
- drive.file (solo file creati dall'app)
HubSpot Scopes:
- crm.objects.contacts.read
- crm.objects.deals.write
- conversations.read
- tickets (lettura e scrittura ticket)
Best Practice per gli Scopes
- Richiedi sempre il minimo necessario (prefer read-only se non devi scrivere)
- Richiedi scopes aggiuntivi solo quando l'utente usa la funzionalità che li richiede (incremental authorization)
- Documenta chiaramente perché ogni scope è necessario: gli utenti lo verificheranno
- Non richiedere mai scope "superutente" o di admin se non assolutamente necessario
Sicurezza OAuth: Punti Critici
PKCE: Obbligatorio per App Native e SPA
Proof Key for Code Exchange (PKCE) è un'estensione di sicurezza che protegge il flusso OAuth nelle app native (mobile) e nelle Single Page Application dove il client_secret non può essere mantenuto segreto. L'app genera un code_verifier casuale prima del redirect, lo hasha (code_challenge), e lo invia nell'authorization request. Al momento dello scambio code→token, invia il code_verifier originale che viene verificato server-side.
Parametro State: Prevenzione CSRF
Il parametro "state" è un valore casuale generato prima del redirect di autorizzazione. Quando il server OAuth rimanda l'utente al redirect_uri, include lo stesso state. L'applicazione verifica che lo state ricevuto corrisponda a quello inviato. Questo previene attacchi CSRF dove un attaccante potrebbe indurre l'utente a completare un flusso OAuth non voluto.
Refresh Token Rotation
Per sicurezza avanzata, alcuni server OAuth implementano la rotazione del refresh token: ogni volta che viene usato un refresh token per ottenere un nuovo access token, viene emesso anche un nuovo refresh token, e il precedente viene invalidato. Se un refresh token rubato viene usato, il sistema se ne accorge (il token legittimo viene rifiutato) e può invalidare tutta la sessione.
Domande Frequenti
Cos'è OAuth?
OAuth 2.0 è il protocollo standard per l'autorizzazione sicura tra sistemi. Permette a un'applicazione di accedere a risorse su un altro servizio per conto di un utente, senza che l'utente debba condividere le proprie credenziali. L'utente autorizza esplicitamente i permessi specifici (scopes), riceve un token di accesso limitato e temporaneo, e può revocare l'accesso in qualsiasi momento.
Perché usare OAuth invece di una password?
Con le password condivise, l'app ha accesso illimitato e revocarle richiede di cambiare la password stessa. OAuth introduce token temporanei con scopes limitati: puoi revocare l'accesso a una singola app senza impattare le altre, i permessi sono espliciti e visibili, e se un token viene compromesso il danno è limitato allo scope e alla durata del token.
OAuth è sicuro?
OAuth 2.0 con PKCE è considerato lo standard di sicurezza attuale per l'autorizzazione delegata. È sicuro se implementato correttamente: HTTPS obbligatorio su tutti i redirect, validazione del parametro state, PKCE per app native e SPA, scadenze brevi per gli access token, e revoca dei token non più necessari. Una API key statica senza scadenza è generalmente meno sicura di un flusso OAuth ben implementato.
Termini Correlati
Implementa OAuth 2.0 nella Tua Azienda
Scopri come V Support può aiutarti a sfruttare l'AI per il tuo customer service. Demo gratuita di 30 minuti.