Ti sarà capitato di accedere a un'applicazione utilizzando un pulsante come “Continua con Google” oppure di autorizzare un servizio a collegarsi a un altro account.
Dietro molte di queste integrazioni troviamo OAuth 2.0, uno dei protocolli più utilizzati per gestire l'accesso delegato alle risorse.
È uno strumento estremamente utile, soprattutto quando si sviluppano applicazioni SaaS che devono comunicare con servizi esterni.
Tuttavia, OAuth 2.0 introduce diversi passaggi che devono essere implementati correttamente.
Una configurazione sbagliata può consentire accessi non autorizzati, intercettazione di codici di autorizzazione o utilizzo improprio dei token.
Vediamo come funziona e quali accorgimenti adottare.
Che cos'è OAuth 2.0?
OAuth 2.0 è un framework di autorizzazione che consente a un'applicazione di ottenere accesso limitato a risorse protette da un altro servizio.
Il vantaggio principale è che l'utente non deve necessariamente comunicare la propria password all'applicazione che richiede l'accesso.
Immaginiamo un gestionale che deve consultare alcuni dati di un calendario esterno.
Invece di chiedere all'utente di inserire direttamente le credenziali del calendario, il gestionale può avviare un flusso OAuth.
L'utente viene indirizzato al servizio che gestisce l'account, effettua l'autenticazione e autorizza l'accesso richiesto.
Il gestionale riceve quindi le credenziali necessarie per utilizzare le API consentite.
OAuth 2.0 è un protocollo di autenticazione?
Non esattamente.
OAuth 2.0 nasce come framework di autorizzazione.
Serve principalmente a delegare l'accesso a determinate risorse.
Per implementare l'autenticazione degli utenti, molte piattaforme utilizzano OpenID Connect, un livello costruito sopra OAuth 2.0.
OpenID Connect introduce meccanismi standardizzati per ottenere informazioni sull'identità dell'utente.
Questa distinzione è importante perché un'applicazione non dovrebbe utilizzare arbitrariamente un access token OAuth come prova dell'identità dell'utente.
L'access token è destinato all'accesso alle risorse, mentre l'ID token di OpenID Connect ha uno scopo differente.
I principali componenti di OAuth 2.0
Per comprendere il funzionamento del protocollo bisogna conoscere alcuni elementi.
Resource Owner: il soggetto che può autorizzare l'accesso alle risorse.
Client: l'applicazione che richiede l'accesso.
Authorization Server: il servizio che gestisce l'autorizzazione ed emette i token.
Resource Server: il servizio che ospita le risorse protette.
In molti casi, authorization server e resource server appartengono alla stessa piattaforma, ma svolgono ruoli differenti.
Come funziona Authorization Code Flow
Uno dei flussi più utilizzati nelle applicazioni web moderne è l'Authorization Code Flow.
Il funzionamento generale è questo:
- L'utente avvia il collegamento a un servizio esterno.
- L'applicazione lo reindirizza all'authorization server.
- L'utente effettua l'autenticazione e autorizza i permessi richiesti.
- Il provider reindirizza il browser verso l'applicazione con un codice di autorizzazione.
- L'applicazione scambia il codice con un access token.
- Il token viene utilizzato per accedere alle API consentite.
Il codice di autorizzazione ha una durata limitata ed è destinato a essere utilizzato una sola volta.
È importante che l'applicazione verifichi correttamente tutti i parametri previsti dal flusso.
Che cos'è PKCE e perché è importante?
PKCE significa Proof Key for Code Exchange.
È un meccanismo progettato per proteggere il flusso di autorizzazione da determinate forme di intercettazione o utilizzo improprio del codice.
Il client genera un valore casuale chiamato code_verifier.
Da questo valore deriva un code_challenge, generalmente utilizzando SHA-256.
Il code_challenge viene inviato durante la richiesta iniziale di autorizzazione.
Quando il client scambia il codice con un token, presenta il code_verifier.
Il server verifica che corrisponda alla challenge ricevuta in precedenza.
In questo modo, un codice di autorizzazione intercettato non dovrebbe essere sufficiente per ottenere il token senza conoscere anche il verifier.
PKCE è una protezione raccomandata nelle implementazioni moderne dell'Authorization Code Flow, anche per i client riservati.
Come generare un code verifier in PHP
PHP permette di generare valori casuali attraverso random_bytes().
Un esempio semplificato:
<?php
$codeVerifier = rtrim(
strtr(
base64_encode(random_bytes(32)),
'+/',
'-_'
),
'='
);
$codeChallenge = rtrim(
strtr(
base64_encode(
hash('sha256', $codeVerifier, true)
),
'+/',
'-_'
),
'='
);
Il valore codeChallenge viene utilizzato nella richiesta di autorizzazione con il metodo S256.
Il codeVerifier deve essere conservato in modo sicuro e associato alla specifica richiesta di autorizzazione.
Durante lo scambio del codice, il client invia il verifier originale.
Questo esempio illustra soltanto la generazione dei valori: non costituisce un'implementazione completa di OAuth.
L'importanza del parametro state
Un altro elemento fondamentale è il parametro state.
Il client può utilizzarlo per collegare la risposta di autorizzazione alla richiesta originaria e contribuire alla protezione contro attacchi CSRF.
Il valore deve essere imprevedibile e associato correttamente alla sessione o alla transazione di autorizzazione.
Quando il provider reindirizza l'utente verso l'applicazione, il client deve verificare che lo state ricevuto corrisponda a quello atteso.
Non bisogna utilizzare valori statici o facilmente prevedibili.
È importante ricordare che PKCE e state hanno ruoli distinti e che le protezioni necessarie dipendono dal flusso e dal protocollo utilizzato.
Redirect URI: uno degli errori più delicati
Durante il processo OAuth, il provider deve sapere dove inviare l'utente dopo l'autorizzazione.
Questa destinazione viene indicata attraverso il parametro redirect_uri.
Una configurazione troppo permissiva può essere pericolosa.
Per esempio, se un provider accetta qualsiasi URL che contiene il nome del dominio autorizzato, potrebbe essere possibile indirizzare la risposta verso una destinazione non prevista.
Per questo motivo, i redirect URI devono essere registrati e confrontati secondo regole rigorose.
Nelle implementazioni moderne è generalmente necessario utilizzare corrispondenze esatte con gli URI autorizzati, salvo le eccezioni previste dalle specifiche applicabili.
Non è sufficiente verificare che l'indirizzo contenga una determinata stringa.
Perché bisogna limitare gli scope
Gli scope rappresentano i permessi richiesti dal client.
Un'applicazione potrebbe aver bisogno soltanto di leggere alcuni dati, senza modificarli.
In questo caso non dovrebbe richiedere autorizzazioni più ampie del necessario.
Il principio del privilegio minimo si applica anche a OAuth.
Se un token viene compromesso, i danni potenziali dipendono anche dalle operazioni che quel token permette di effettuare.
È quindi opportuno richiedere soltanto gli scope realmente necessari.
Access token e refresh token
OAuth 2.0 può utilizzare access token e refresh token.
L'access token consente al client di accedere alle risorse autorizzate.
Il refresh token, quando previsto, permette di ottenere nuovi access token senza ripetere completamente il processo di autorizzazione.
I refresh token richiedono particolare attenzione perché possono avere una durata maggiore.
Devono essere conservati in modo sicuro e protetti secondo le caratteristiche del client.
Per i client pubblici, le raccomandazioni moderne prevedono meccanismi come la rotazione dei refresh token oppure tecniche di sender-constraining.
Dove conservare i token OAuth?
La risposta dipende dall'architettura.
In un'applicazione web con backend PHP, può essere opportuno mantenere i token destinati alle API esterne sul server, evitando di esporli inutilmente al browser.
Le credenziali devono essere protette attraverso permessi appropriati, cifratura quando necessaria e controlli di accesso.
Se i token sono associati a utenti differenti, l'applicazione deve garantire che ciascun utente possa utilizzare soltanto le proprie autorizzazioni.
Questo aspetto è particolarmente importante nei sistemi multi-tenant.
Un errore di isolamento potrebbe consentire a un cliente di utilizzare credenziali associate a un altro tenant.
Gli errori OAuth più comuni
Durante lo sviluppo è importante evitare alcune situazioni.
Non verificare correttamente il redirect URI
Può consentire l'invio di risposte di autorizzazione verso destinazioni non previste.
Non utilizzare PKCE quando richiesto
Può aumentare il rischio associato all'intercettazione dei codici di autorizzazione.
Gestire male il parametro state
Può rendere vulnerabile il flusso a determinate forme di CSRF o confusione tra richieste.
Conservare i token in modo insicuro
Può consentire il furto delle credenziali attraverso vulnerabilità applicative.
Richiedere scope eccessivi
Aumenta le conseguenze di un'eventuale compromissione.
Non verificare correttamente i token
Un'applicazione deve controllare le proprietà rilevanti dei token secondo il protocollo e il ruolo svolto.
Per esempio, un ID token OpenID Connect richiede verifiche differenti rispetto a un access token destinato a un'API.
OAuth 2.0 nelle applicazioni SaaS
Per una piattaforma SaaS, OAuth può diventare uno strumento fondamentale.
Permette di collegare account esterni, sincronizzare informazioni e utilizzare servizi di terze parti.
Ma introduce anche responsabilità operative.
È importante gestire correttamente il rinnovo dei token, la revoca delle autorizzazioni e l'isolamento delle credenziali tra utenti e organizzazioni.
Una buona implementazione dovrebbe prevedere anche una procedura chiara per scollegare un account esterno.
Quando un utente revoca l'accesso, l'applicazione deve interrompere l'utilizzo delle credenziali associate.
Come verificare la sicurezza di un'integrazione OAuth
Durante una revisione tecnica è utile controllare:
- I flussi di autorizzazione utilizzati.
- La presenza e la verifica di PKCE.
- La gestione dello
state. - I redirect URI autorizzati.
- Gli scope richiesti.
- La conservazione dei token.
- Le procedure di revoca.
- L'isolamento tra utenti e tenant.
È importante utilizzare librerie affidabili e aggiornate, evitando implementazioni personalizzate non necessarie.
Per approfondire puoi consultare le raccomandazioni di sicurezza contenute nella RFC 9700, dedicata alle migliori pratiche per OAuth 2.0.
Conclusione
OAuth 2.0 permette di costruire integrazioni potenti senza richiedere agli utenti di condividere direttamente le proprie password.
Ma la sicurezza dipende dalla corretta implementazione del protocollo.
PKCE, redirect URI rigorosi, gestione dello stato, protezione dei token e limitazione degli scope sono elementi fondamentali.
Un'integrazione OAuth sicura non deve soltanto funzionare: deve garantire che ogni autorizzazione venga utilizzata esclusivamente dal client e dall'utente previsti.
Con MiHakero puoi affiancare alla revisione delle integrazioni il monitoraggio delle esposizioni esterne e delle configurazioni dei tuoi servizi pubblici.
SEO Meta Title: OAuth 2.0: sicurezza, PKCE ed errori da evitare
SEO Meta Description: Scopri come proteggere OAuth 2.0 con PKCE, state, redirect URI sicuri e gestione corretta dei token nelle applicazioni web.