OAuth 2.0

OAuth 2.0 è il protocollo standard per l’autorizzazione delegata — consente a un’applicazione di terze parti di accedere alle risorse che controlli su un altro servizio senza consegnare la tua password. “Accedi con Google”, “Connetti il tuo account GitHub”, “Consenti a Zapier di accedere alla tua Gmail” usano tutti OAuth.

I quattro ruoli: proprietario della risorsa (l’utente), client (l’app di terze parti), server di autorizzazione (il servizio che emette OAuth, ad es. accounts.google.com), server delle risorse (l’API che il client vuole chiamare, ad es. gmail.googleapis.com).

Il flusso piú comune (codice di autorizzazione con PKCE):

1. Il client reindirizza l’utente al server di autorizzazione.
2. L’utente accede e approva gli ambiti richiesti.
3. Il server di autorizzazione reindirizza con un codice di autorizzazione usa e getta.
4. Il client scambia il codice (più il verificatore PKCE) per un token di accesso.
5. Il client chiama il server delle risorse con il token di accesso.

OAuth 2.0 è solo per l’autorizzazione. OpenID Connect (OIDC) è il livello di autenticazione sopra — aggiunge un token ID (un JWT con claim su chi è l’utente) cosicché il client sappia chi ha effettuato l’accesso, non solo “un utente autorizzato qualsiasi”. La maggior parte dei flussi moderni “Accedi con X” sono OIDC, non OAuth puro.

Perché PKCE è ora obbligatorio per i client pubblici: il flusso originale di codice di autorizzazione OAuth 2.0 presupponeva che il client potesse mantenere un segreto. Le app mobile e le single-page app non possono — chiunque può smontare l’app ed estrarre il segreto incorporato. PKCE (Proof Key for Code Exchange, RFC 7636) sostituisce il segreto client statico con un verificatore casuale per flusso con hash via SHA-256: il client invia prima l’hash e rivela il testo in chiaro solo quando scambia il codice, dimostrando di essere lo stesso client che ha avviato il flusso. PKCE è ora richiesto per tutti i client pubblici (OAuth 2.1, RFC 9700 BCP) e consigliato anche per i client riservati come difesa in profondità.

I quattro flussi da conoscere e i due da evitare: usa Authorization Code + PKCE per quasi tutto (web, mobile, SPA). Usa Client Credentials per chiamate API machine-to-machine senza utente presente. Il flusso Implicit (restituisce token di accesso direttamente nei frammenti URL) e il flusso Resource Owner Password Credentials (il client raccoglie direttamente la password) sono entrambi deprecati in OAuth 2.1 — nessuno dei due protegge adeguatamente dagli attacchi moderni. Qualsiasi nuova integrazione OAuth dovrebbe rifiutarli anche se un fornitore li offre. Correlati: JWT, SAML. Riferimento: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Esempio pratico

Un pulsante “Connetti Slack” nel tuo SaaS attiva un reindirizzamento a https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. L’utente approva; Slack reindirizza a https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Il tuo backend esegue un POST a https://slack.com/api/oauth.v2.access con il codice, il verificatore PKCE originale e l’ID client. Slack restituisce {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. Salvi il token di accesso lato server (mai nel local storage del browser) e lo usi come Authorization: Bearer xoxb-... nelle successive chiamate API di Slack. L’intero scambio richiede qualche centinaio di millisecondi; l’utente vede una schermata di consenso e non digita mai una password Slack nella tua app.

Quando e perché è importante

Le configurazioni errate di OAuth sono una delle categorie piú sfruttate nella sicurezza web moderna. Modalità di errore comuni: mancata validazione del parametro state (abilita CSRF sul callback), consentire caratteri jolly nella registrazione di redirect_uri (abilita il furto di token tramite open-redirect), archiviare i token di accesso in storage accessibile dal browser (esfiltrazione XSS), e trattare i token di aggiornamento come token bearer a lungo termine invece di ruotarli all’uso. La OAuth 2.0 Security Best Current Practice (RFC 9700, pubblicata nel 2025) codifica i valori predefiniti moderni: PKCE ovunque, redirect URI con corrispondenza esatta, token vincolati al mittente (DPoP o mTLS) per API ad alto valore e rotazione dei token di aggiornamento con rilevamento del riutilizzo. Seguire queste pratiche trasforma la maggior parte dei risultati di pen test OAuth in non-problemi. Riferimento: RFC 9700 — OAuth 2.0 Security BCP.