# OAuth 2.0: le nuove best practice di sicurezza (RFC 9700)
Table of Contents
A gennaio 2025 l’IETF - l’organismo che cura gli standard tecnici di Internet - ha pubblicato la RFC 9700, intitolata “Best Current Practice for OAuth 2.0 Security”. Il documento raccoglie in forma ufficiale e aggiornata le regole di sicurezza consigliate per chi usa OAuth 2.0, il meccanismo dietro al classico “Accedi con Google” e a gran parte delle API protette del web. Non introduce un protocollo nuovo: mette ordine, aggiorna i consigli esistenti e segna come da evitare alcune pratiche ormai considerate rischiose.
Cos’è OAuth 2.0, in breve
OAuth 2.0 è uno standard per l’autorizzazione delegata. Detto in modo semplice: permette a un’applicazione di ottenere un accesso limitato a un servizio per conto di una persona, senza che quella persona debba consegnare la propria password all’applicazione. È quello che succede quando un sito chiede “Accedi con Google” oppure “Collega il tuo account”. Il servizio di origine verifica l’identità e rilascia all’applicazione un token, cioè un gettone temporaneo che vale come permesso d’accesso, con limiti precisi su cosa può fare e per quanto tempo.
Il vantaggio è evidente. La password resta al servizio di origine, l’applicazione riceve solo il minimo necessario, e quel permesso si può revocare in qualsiasi momento. Proprio per questo OAuth 2.0 è diventato lo scheletro di login e API su gran parte del web: dai social alle piattaforme cloud, fino alle integrazioni tra software aziendali.
Conviene chiarire subito tre termini che torneranno utili. Un access token è il gettone che dà accesso a una risorsa. Un authorization code (codice di autorizzazione) è un passaggio intermedio: un codice breve che l’applicazione scambia poi con il token vero. Un redirect URI è l’indirizzo a cui il servizio rimanda l’utente dopo il consenso, e su cui recapita quel codice.
Perché un riferimento aggiornato conta
OAuth 2.0 è stato pubblicato nel 2012 (RFC 6749). Da allora è stato adottato quasi ovunque, e con l’adozione su larga scala sono emersi attacchi e insidie che all’inizio non erano chiari. Le regole di sicurezza originali si sono rivelate in alcuni punti troppo generiche, in altri superate.
La RFC 9700 nasce per questo. È una Best Current Practice - in sigla BCP, con numero 240 - cioè un documento che non descrive un nuovo standard tecnico, ma raccoglie la pratica migliore consigliata dalla comunità in un dato momento. In concreto aggiorna ed estende tre documenti precedenti: la specifica base di OAuth 2.0 (RFC 6749), le regole sull’uso dei token “bearer” (RFC 6750) e il vecchio modello delle minacce (RFC 6819). L’obiettivo dichiarato è incorporare l’esperienza raccolta sul campo e coprire minacce nuove, nate dall’uso sempre più esteso del protocollo.
Un punto importante: non è una bozza né una proposta. È un documento pubblicato a gennaio 2025, al livello di “pratica corrente” ufficiale. Gli autori sono Torsten Lodderstedt (SPRIND), John Bradley (Yubico), Andrey Labunets e Daniel Fett (Authlete), nomi noti nell’ambito dell’identità digitale.
Le raccomandazioni principali
Il testo è lungo e dettagliato, ma alcune indicazioni riassumono bene la direzione.
PKCE per le applicazioni pubbliche. PKCE è un meccanismo che lega la richiesta iniziale allo scambio finale del codice, così che un codice intercettato non basti da solo a ottenere il token. La RFC lo rende obbligatorio per i client “pubblici” - app mobili e applicazioni che girano nel browser, che non possono custodire un segreto - e lo consiglia anche per gli altri. I server di autorizzazione devono supportarlo e verificarlo, in modo che un attaccante non possa aggirarlo.
Corrispondenza esatta dei redirect URI. Il server deve confrontare l’indirizzo di ritorno con quelli registrati in anticipo carattere per carattere, senza scorciatoie. È una difesa contro il dirottamento del codice di autorizzazione verso un sito controllato dall’attaccante. L’unica eccezione pratica riguarda le app native su “localhost”, dove il numero di porta può variare.
Token legati a chi li usa. Un rischio classico è il furto del token: chi lo ruba lo può riutilizzare. La RFC raccomanda i sender-constrained token, cioè token vincolati al client legittimo, tramite mutual TLS (RFC 8705) o DPoP (RFC 9449). In pratica il token da solo non basta: serve anche la prova di essere il titolare originale.
Protezione dei refresh token. Il refresh token è un gettone a vita più lunga che serve a ottenere nuovi access token senza rifare il login. Per le applicazioni pubbliche la RFC chiede che sia anch’esso vincolato al client, oppure che venga ruotato, cioè sostituito a ogni uso, così che un token rubato smetta presto di funzionare.
Difesa dagli attacchi “mix-up”. Quando un’applicazione dialoga con più server di autorizzazione, un attaccante può cercare di confondere le risposte tra l’uno e l’altro. La contromisura richiesta è identificare con chiarezza chi ha emesso la risposta (tramite il parametro iss) oppure usare indirizzi di ritorno distinti per ciascun server.
A queste si aggiungono due regole di base: le risposte di autorizzazione non devono mai viaggiare su connessioni non cifrate, e conviene affidarsi ai metadati del server di autorizzazione per attivare in automatico le opzioni di sicurezza, riducendo gli errori di configurazione.
Cosa viene sconsigliato o eliminato
Parte del valore della RFC 9700 sta in ciò che toglie.
Viene abbandonato l’implicit grant, un vecchio flusso che consegnava l’access token direttamente nella risposta del browser: comodo un tempo, ma esposto a fughe e riuso del token. Al suo posto va usato il flusso con codice di autorizzazione e PKCE.
Viene escluso del tutto il resource owner password credentials, il flusso in cui l’utente digita la propria password direttamente nell’applicazione, che poi la gira al servizio. Vanifica il senso stesso di OAuth - non far passare la password dalle mani dell’applicazione - ed è incompatibile con l’autenticazione a più fattori. La RFC dice chiaramente che non deve essere usato.
Perché conta per chi espone login e API
Per chi gestisce un servizio con login sociale o API protette, la RFC 9700 è il riferimento a cui allinearsi. Non impone di riscrivere tutto domani, ma indica con chiarezza cosa è considerato sicuro oggi e cosa no.
Vale come lista di controllo pratica: verificare che sia attivo PKCE, che i redirect URI siano confrontati in modo esatto, che i flussi implicit e password siano stati dismessi, che i refresh token vengano ruotati o vincolati. Chi sviluppa integrazioni ha ora un documento unico e citabile a cui riferirsi nelle scelte tecniche e nelle verifiche di sicurezza. E chi usa librerie o provider di identità di terze parti può adottarlo come metro per capire se seguono la pratica aggiornata.
Il messaggio di fondo è semplice: OAuth 2.0 resta valido, ma il modo sicuro di usarlo si è affinato con l’esperienza. Avere quel modo scritto nero su bianco, in un documento ufficiale, aiuta a ridurre gli errori più comuni.
