# Cloudflare apre l'OAuth self-managed a tutti gli sviluppatori
Table of Contents
Chi costruisce un programma che deve “parlare” con un servizio online - per esempio un’applicazione che gestisce siti, DNS o firewall per conto di un cliente - prima o poi si scontra con una domanda pratica: come faccio a far accedere il mio software all’account di qualcun altro, in modo sicuro e senza chiedergli la password? Il 3 giugno 2026 Cloudflare, uno dei maggiori operatori di rete e CDN al mondo, ha reso disponibile a tutti i propri clienti uno strumento pensato proprio per questo: l’OAuth “self-managed”, cioè la possibilità di creare da sé le proprie applicazioni OAuth. Fino a poco prima era una funzione riservata a un ristretto gruppo di partner approvati a mano; ora può usarla chiunque abbia un account.
Il punto di partenza: i token API
Per capire la notizia conviene partire da come si accede oggi alle API di Cloudflare. Un’API è l’interfaccia con cui un programma comanda un servizio senza passare dal sito: creare un record DNS, aggiungere una regola, leggere delle statistiche. Per autorizzare queste operazioni si usa in genere un token API: una lunga stringa segreta che funziona come una chiave. Chi ce l’ha può compiere le azioni che quel token permette.
I token risolvono il problema, ma hanno alcuni limiti fastidiosi quando si costruiscono integrazioni per altri. Sono spesso a lunga durata e con permessi ampi, perché è comodo generarne uno che “faccia tutto”. Vanno consegnati al programma che li userà, e questo significa condividere un segreto: se finisce nel posto sbagliato, magari attraverso una dipendenza software compromessa come è successo di recente ai pacchetti npm messi in quarantena, chi lo ha in mano può agire sull’account finché il token non viene cancellato. E se un cliente vuole revocare l’accesso a una singola applicazione, districare quale token appartiene a chi non è sempre immediato. In breve: comodi per l’uso personale, poco adatti a delegare un accesso limitato a software di terzi.
Cos’è OAuth e cosa cambia
OAuth è uno standard di autorizzazione diffuso in tutto il web. È lo stesso meccanismo che c’è dietro i pulsanti “Accedi con Google” o “Collega il tuo account”: invece di consegnare una password o una chiave, l’utente viene mandato sul sito del servizio, gli conferma quali permessi concedere all’applicazione e torna indietro con un’autorizzazione limitata. L’applicazione non vede mai le credenziali dell’utente; riceve solo il permesso di fare quel poco che le è stato concesso.
Rispetto a un token consegnato a mano, il modello OAuth porta tre vantaggi concreti. Il primo è il consenso esplicito: è l’utente a decidere, davanti a una schermata chiara, cosa autorizzare. Il secondo è il minimo privilegio: l’applicazione chiede solo i permessi che le servono, non le chiavi di tutto. Il terzo è la revoca pulita: l’utente può togliere l’accesso a quella singola applicazione dal proprio pannello, senza toccare il resto.
Cosa ha annunciato Cloudflare
La novità è che ora qualsiasi cliente Cloudflare può creare e gestire in autonomia le proprie applicazioni OAuth, senza dover essere un partner selezionato. Si fa dal pannello, alla voce Manage account > OAuth clients, oppure via API per chi preferisce automatizzare. Da lì si definisce l’applicazione, si scelgono i permessi e si ottengono le credenziali necessarie a far partire il flusso di autorizzazione.
È una funzione disponibile a tutti (general availability), non una beta. Cloudflare la descrive come un’alternativa ai token API più sicura, più comoda da usare e più facile da gestire, soprattutto per gli scenari in cui un’applicazione agisce per conto di un utente.
Permessi su misura
Il cuore della cosa sono gli scope, cioè i permessi che un’applicazione può richiedere. Su Cloudflare i nomi degli scope corrispondono ai permessi che si troverebbero anche creando un token API: si può quindi scegliere in modo granulare a cosa dare accesso - per esempio la sola lettura del DNS di una zona, o la sola gestione di una certa funzione - invece di concedere tutto in blocco. L’elenco degli scope disponibili si può consultare dal pannello durante la creazione del client, oppure recuperare via API.
L’effetto pratico è che un’integrazione ben fatta chiede solo ciò che le serve. Se domani quell’applicazione viene compromessa, il danno resta confinato ai permessi concessi, non all’intero account.
Client privati e pubblici, e la schermata di consenso
Cloudflare distingue due tipi di applicazione. Un client privato può essere autorizzato solo dai membri dell’account che lo ha creato: è pensato per gli strumenti interni di un’organizzazione. Un client pubblico può invece essere autorizzato da qualsiasi utente Cloudflare: è il caso di un prodotto SaaS che offre un pulsante “collega il tuo account Cloudflare” ai propri clienti.
Per i client pubblici c’è un passaggio in più a tutela degli utenti: la verifica del dominio. Chi pubblica l’applicazione deve dimostrare di controllare il proprio dominio inserendo un record DNS di tipo TXT con un codice fornito da Cloudflare. Superata la verifica, l’applicazione ottiene un badge sulla schermata di consenso, così chi sta per autorizzarla sa con chi ha a che fare. La stessa schermata è stata rivista per mostrare in modo chiaro quale applicazione chiede l’accesso e quali permessi riceve.
Client secret e PKCE
Un dettaglio tecnico utile per chi svilupperà queste integrazioni: Cloudflare supporta il flusso OAuth 2.0 chiamato authorization code, in linea con le più recenti raccomandazioni di sicurezza per OAuth, ed esclude altri tipi meno adatti a un accesso delegato sicuro. In questo flusso, un’applicazione che gira su un server proprio può custodire un client secret, cioè una password dell’applicazione tenuta al riparo. Le applicazioni che invece girano interamente sul dispositivo dell’utente - un’app mobile, un programma desktop, una pagina web - non possono nascondere un segreto e devono usare un meccanismo chiamato PKCE, che protegge lo scambio senza bisogno di custodire una chiave. È una distinzione importante: il consiglio esplicito è di non incorporare mai il client secret nel codice che finisce sul dispositivo dell’utente.
A cosa serve
Gli scenari che si aprono sono soprattutto tre. Il primo sono i prodotti SaaS che gestiscono infrastruttura Cloudflare per conto dei clienti: ora possono offrire un vero flusso “collega il tuo account”, con permessi mirati, al posto di chiedere all’utente di generare e incollare un token. Il secondo sono le piattaforme interne di sviluppo: un’azienda può costruire strumenti che agiscono sulle proprie risorse Cloudflare con autorizzazioni per singolo utente. Il terzo, più recente, riguarda gli agenti AI e i server MCP - programmi che agiscono per conto di una persona: anche loro hanno finalmente un modello di accesso delegato pensato per lo scopo, invece di doversi far consegnare un token a permessi ampi.
Perché conta
Il valore non sta in una singola funzione appariscente, ma nel togliere frizione a un problema ricorrente. Chi costruisce integrazioni può chiedere solo i permessi necessari, gli utenti vedono con chiarezza cosa stanno autorizzando e possono revocare l’accesso a una specifica applicazione con un clic. È il modello a cui gran parte del web è già abituata, esteso ora anche alle API di Cloudflare e aperto a chiunque, non più ai soli partner.
Va detto con onestà che questo non manda in pensione i token API: per gli usi personali o per gli script rapidi restano più semplici e diretti. L’OAuth self-managed brilla quando c’è di mezzo una terza parte e serve delegare un accesso limitato in modo controllato. Sotto il cofano, per rendere il servizio disponibile a tutti, Cloudflare ha aggiornato il motore OAuth su cui si appoggia (il progetto open source Ory Hydra) con una migrazione senza interruzioni: un lavoro invisibile all’utente, ma che spiega perché la funzione arriva solo ora. Per chi costruisce integrazioni con Cloudflare, è un tassello che finora mancava e che vale la pena provare su un progetto reale.
