OAuth 2.0

Voci di Glossario Sicurezza Informatica
Indice dei contenuti

    OAuth 2.0 (RFC 6749) è un framework di autorizzazione delegata — non di autenticazione. Permette a un’applicazione (client) di accedere a risorse protette per conto di un utente (resource owner), senza che l’utente riveli le proprie credenziali al client. Questa distinzione è fondamentale: OAuth 2.0 autorizza l’accesso a dati, non verifica identità. Per l’autenticazione sopra OAuth 2.0 si usa OpenID Connect.

    Il problema che risolve

    Prima di OAuth, le applicazioni di terze parti che dovevano accedere a dati dell’utente (es. un’app di gestione del calendario che accede a Google Calendar) richiedevano il nome utente e la password dell’utente — che poi conservavano per fare richieste future. Questo era pericoloso: il sito terzo aveva accesso completo all’account, l’utente non poteva revocare l’accesso senza cambiare la password, e ogni breach del sito terzo esponeva le credenziali Google/Facebook/ecc.

    OAuth 2.0 risolve questo sostituendo le credenziali con token di accesso limitati e revocabili.

    Ruoli

    • Resource Owner: l’utente proprietario delle risorse (es. il titolare dell’account Google).
    • Resource Server: il server che ospita le risorse protette (es. le API di Google Calendar).
    • Client: l’applicazione che vuole accedere alle risorse (es. un’app di produttività di terze parti).
    • Authorization Server: il server che autentica il Resource Owner ed emette i token (es. accounts.google.com).

    Authorization Code Flow

    Il flusso principale per applicazioni web con backend:

    1. Client reindirizza l'utente all'Authorization Server con scope e redirect_uri
2. L'utente si autentica e approva l'accesso
3. Authorization Server reindirizza al Client con un authorization code temporaneo
4. Client scambia il code con l'Authorization Server (tramite client_secret) per ottenere access_token e refresh_token
5. Client usa l'access_token per chiamare le API del Resource Server

    Il PKCE (Proof Key for Code Exchange, RFC 7636) estende il flusso per applicazioni mobili e SPA che non possono conservare un client_secret in modo sicuro.

    Token

    L’access token è una stringa opaca (o JWT) che il Client presenta al Resource Server per accedere alle risorse. Ha una durata breve (tipicamente 1 ora). Il refresh token ha durata lunga e permette al Client di ottenere un nuovo access token senza richiedere di nuovo l’autenticazione dell’utente. Lo scope definisce i permessi concessi: calendar.read, contacts.write, ecc.

    Sicurezza

    OAuth 2.0 è un framework, non un protocollo rigido: la sicurezza dipende dall’implementazione. Vulnerabilità comuni includono la mancata validazione del redirect_uri (che permette il redirect dei token verso siti malevoli), l’assenza di PKCE nelle app mobili, e la confusione tra autorizzazione e autenticazione (usare OAuth per login senza OpenID Connect).

    Ultimo aggiornamento: