OAuth 2.0: cos'è e come funziona il protocollo di autorizzazione

Cos'è OAuth 2.0?

OAuth 2.0 è un protocollo di autorizzazione definito in IETF RFC 6749 che consente ad applicazioni terze di ottenere accesso limitato alle risorse di un utente senza rivelare il suo nome utente e password. Il protocollo risolve un problema fondamentale del modello basato su password: un'applicazione a cui affidi la tua password ottiene accesso illimitato a tutti i dati dell'account. OAuth 2.0 sostituisce questo approccio emettendo un token temporaneo con un ambito di accesso esplicitamente limitato.

L'architettura di OAuth 2.0 è l'autorizzazione delegata. L'utente (Resource Owner) autorizza un'applicazione (Client) ad accedere ai propri dati memorizzati su un server di risorse (Resource Server) attraverso un intermediario: il server di autorizzazione (Authorization Server). Il server di autorizzazione emette un Access Token, una stringa crittografica che l'applicazione presenta al server di risorse per accedere ai dati. Una differenza importante tra OAuth 2.0 e SAML o OpenID Connect: OAuth 2.0 risolve il compito di autorizzazione (cosa è permesso), non l'autenticazione (chi è l'utente). Per l'autenticazione su OAuth 2.0 viene costruito il protocollo OpenID Connect (OIDC).

Il protocollo è supportato da tutte le principali piattaforme. Google utilizza OAuth 2.0 per accedere alle Google APIs (Gmail, Drive, Calendar), Facebook per Graph API, Apple per Sign in with Apple (ASAuthorizationAppleIDProvider) e GitHub per l'accesso ai repository. Nel contesto dello sviluppo mobile, OAuth 2.0 è il meccanismo standard per integrare servizi di terze parti: login tramite social network, accesso all'archiviazione cloud e pubblicazione di contenuti per conto dell'utente.

Ruoli e componenti di OAuth 2.0

Il protocollo OAuth 2.0 definisce quattro ruoli la cui interazione forma il ciclo completo di autorizzazione. Comprendere ogni ruolo è essenziale per implementare correttamente il protocollo in un'applicazione mobile.

I quattro ruoli del protocollo

Le entità chiave del protocollo sono l'Access Token, il Refresh Token e l'Authorization Code. L'Access Token è un token di breve durata (solitamente 15–60 minuti) presentato al server di risorse ad ogni richiesta di dati. Il Refresh Token è un token di lunga durata (giorni o settimane) utilizzato per ottenere un nuovo Access Token senza che l'utente debba riaccedere. L'Authorization Code è un codice temporaneo emesso dopo l'autorizzazione dell'utente e scambiato con un Access Token e Refresh Token.

Grant Types: scenari di autorizzazione

OAuth 2.0 definisce diversi Grant Types, scenari di ottenimento del token, ciascuno progettato per un tipo specifico di client e contesto di sicurezza. Scegliere il Grant Type corretto è una decisione architettonica critica nella progettazione dell'autorizzazione in un'applicazione mobile.

I principali Grant Types sono: Authorization Code (il più sicuro per applicazioni mobili e web con componente server), Authorization Code con PKCE (Proof Key for Code Exchange: per applicazioni mobili e SPA senza backend server), Client Credentials (per autenticazione server-to-server senza partecipazione dell'utente) e Resource Owner Password Credentials (deprecato: trasmette la password direttamente). PKCE è un'estensione obbligatoria per client pubblici (applicazioni mobili, SPA) secondo le raccomandazioni di OAuth Security BCP (RFC 9700).

Principali Grant Types

• Authorization Code + PKCE è il Grant Type raccomandato per applicazioni mobili native. Il client genera un code_verifier crittografico, calcola un code_challenge (hash SHA-256) e il server verifica la corrispondenza durante lo scambio del codice per un token. Ciò impedisce l'intercettazione dell'authorization code tra l'applicazione e il server
• Client Credentials viene utilizzato per autorizzazione machine-to-machine dove il client è noto e autenticato. L'applicazione ottiene un token usando il proprio client_id e client_secret. Non richiede partecipazione dell'utente. Scenario tipico: un'applicazione server chiama un'API per l'elaborazione batch di dati
• Device Authorization Grant è per dispositivi senza browser (Smart TV, IoT). L'utente segue un link su un altro dispositivo e inserisce un codice. Utilizzato, ad esempio, durante l'autorizzazione di Netflix su un televisore tramite smartphone
• Resource Owner Password Credentials è un Grant Type deprecato vietato da OAuth Security BCP. La password viene trasmessa direttamente al client, violando il principio di autenticazione a conoscenza zero. Utilizzato solo per la migrazione da sistemi legacy

Authorization Code Flow con PKCE per applicazioni mobili

Authorization Code Flow con PKCE è la configurazione raccomandata di OAuth 2.0 per applicazioni mobili native. PKCE (Proof Key for Code Exchange) aggiunge un ulteriore strato di protezione che previene gli attacchi di intercettazione dell'authorization code. Il protocollo è descritto in IETF RFC 7636.

Sequenza passo-passo di PKCE

La sequenza dei passaggi: (1) il client genera un code_verifier casuale (una stringa di 43–128 caratteri che utilizza solo caratteri non riservati), (2) il client calcola code_challenge = SHA-256(code_verifier), (3) il client apre un browser per l'autorizzazione dell'utente sull'Authorization Server, passando code_challenge, (4) dopo autorizzazione riuscita, il server restituisce l'authorization code all'applicazione tramite uno schema URI personalizzato (deep link dell'app), (5) il client invia authorization code + code_verifier al server, (6) il server verifica SHA-256(code_verifier) === code_challenge ed emette un Access Token + Refresh Token.

Il vantaggio di PKCE: anche se un utente malintenzionato intercetta l'authorization code nello schema URI, non può scambiarlo per un token senza il code_verifier, che è noto solo al client legittimo. Nelle applicazioni mobili, per aprire il browser è opportuno utilizzare Chrome Custom Tabs (Android) o ASWebAuthenticationSession (iOS); ciò garantisce che il browser di sistema non possa accedere al code_verifier dalla memoria dell'applicazione.

Implementazione di OAuth 2.0 su Android tramite AppAuth

AppAuth è l'implementazione di riferimento di OAuth 2.0 e OpenID Connect per applicazioni native, raccomandata dall'IETF. La libreria supporta PKCE, Chrome Custom Tabs, schemi URI personalizzati per restituire l'authorization code e l'aggiornamento automatico dei token. AppAuth per Android è disponibile tramite la dipendenza `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Avviare Chrome Custom Tab per l'autorizzazione
startActivityForResult(intent, REQUEST_CODE_AUTH)

Dopo aver ricevuto l'authorization code (onActivityResult), l'applicazione lo scambia per un Access Token e Refresh Token tramite un TokenRequest. I token vengono salvati in SharedPreferences con crittografia tramite EncryptedSharedPreferences (Android Security Crypto). Il Refresh Token deve essere memorizzato nel KeyStore, un archivio di chiavi hardware inaccessibile ad altre applicazioni. Ogni volta che l'Access Token scade, l'applicazione utilizza il Refresh Token per ottenerne uno nuovo: l'utente non deve autenticarsi nuovamente.

// Scambiare authorization code per token
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token e Refresh Token ricevuti
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Salvare in EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

Il codice sopra dimostra il flusso completo di OAuth 2.0 con PKCE: creazione della configurazione del server tramite OpenID Connect Discovery, generazione di una richiesta di autorizzazione con code_verifier, avvio di Chrome Custom Tab, ricezione dell'authorization code tramite uno schema URI personalizzato e scambio del codice per token tramite una TokenRequest. È importante gestire la scadenza dell'Access Token: quando si riceve una risposta HTTP 401 dal Resource Server, l'applicazione deve utilizzare il Refresh Token per ottenere un nuovo Access Token ed eseguire nuovamente la richiesta.

Sicurezza di OAuth 2.0: attacchi tipici e protezione

OAuth 2.0 è un protocollo complesso con molti vettori di attacco. IETF Security BCP (RFC 9700) descrive oltre 20 classi di vulnerabilità di OAuth 2.0. Per le applicazioni mobili, le più critiche sono: intercettazione dell'authorization code tramite schemi URI personalizzati, attacchi CSRF sugli endpoint di callback, furto del Refresh Token da archiviazioni non sicure e impersonificazione del client tramite intercettazione di intent.

La protezione contro questi attacchi include misure obbligatorie: (1) PKCE con code_challenge S256: previene l'intercettazione dell'authorization code anche se lo schema URI viene intercettato; (2) utilizzo di un parametro nonce o state per prevenire CSRF: il server verifica che l'authorization code corrisponda alla richiesta originale; (3) memorizzazione del Refresh Token solo nel KeyStore (Android) o Keychain (iOS): mai in SharedPreferences o UserDefaults; (4) utilizzo di TLS con Certificate Pinning per proteggersi da MITM a livello di trasporto; (5) validazione di redirect_uri: il server di autorizzazione deve validare rigorosamente la corrispondenza con l'URI registrato.

Raccomandazioni aggiuntive dell'IETF: le applicazioni mobili dovrebbero utilizzare AppAuth o librerie simili che hanno superato audit di sicurezza; non fare affidamento su WebView per OAuth (WebView non isola i dati dall'applicazione principale); implementare la rotazione automatica del Refresh Token (ogni Refresh Token può essere utilizzato una sola volta); aggiungere Certificate Pinning tramite TrustManager per Android e URLSession per iOS. OpenID Connect Discovery (endpoint well-known) aiuta a determinare automaticamente gli endpoint corretti del server di autorizzazione ed evitare reindirizzamenti a pagine di phishing.