Flussi OAuth 2.0 e tipi di token

OAuth 2.0 definisce quattro ruoli. Il proprietario della risorsa è l'utente che possiede i dati, ad esempio i propri file di Google Drive. Il client è l'applicazione che richiede l'accesso. Il server di autorizzazione emette i token di accesso, ad esempio il server OAuth di Google. Il server delle risorse ospita i dati protetti, ad esempio l'API di Google Drive. Comprendere questi ruoli chiarisce lo scopo di ogni flusso.

Il flusso del codice di autorizzazione è quello corretto per le applicazioni web lato server. L'utente esegue l'autenticazione presso il server di autorizzazione, che reindirizza al client con un codice di autorizzazione di breve durata. Il server del client scambia questo codice con i token tramite una richiesta back-channel. I token non passano mai attraverso il browser, proteggendoli dalla cronologia del browser e dalla divulgazione tramite il referrer.

Il flusso implicito è stato progettato per le applicazioni JavaScript eseguite esclusivamente nel browser, che non potevano archiviare in modo sicuro i segreti del client. I token venivano restituiti direttamente nel frammento dell'URL, evitando il back-channel. Il flusso implicito è deprecato in OAuth 2.1 perché PKCE (RFC 7636) consente ai client pubblici di utilizzare in modo sicuro il flusso del codice di autorizzazione senza un segreto del client.

Il flusso ROPC consente ai client di raccogliere direttamente il nome utente e la password dell'utente e di scambiarli con i token. Era destinato a client proprietari altamente attendibili, ma contraddice fondamentalmente lo scopo di OAuth, che consiste nell'impedire alle applicazioni di vedere le credenziali degli utenti. È deprecato in OAuth 2.1 e non deve essere utilizzato in alcuna nuova applicazione.

Il flusso delle credenziali client è destinato all'autenticazione machine-to-machine (M2M), quando non è coinvolto alcun utente. Il client esegue direttamente l'autenticazione presso il server di autorizzazione utilizzando il proprio ID client e il proprio segreto, ricevendo un token di accesso da utilizzare per conto proprio. Casi d'uso comuni: processi in background, comunicazione tra microservizi e gateway API che accedono ai servizi backend.

Il flusso di autorizzazione del dispositivo (RFC 8628) abilita OAuth sui dispositivi con capacità di input limitate: smart TV, console di gioco, stampanti e dispositivi IoT. Il dispositivo mostra un codice breve e un URL. L'utente visita l'URL tramite un telefono o un computer per autorizzare l'accesso. Il dispositivo interroga ripetutamente il server di autorizzazione finché l'utente non completa l'autorizzazione.

OAuth 2.0 definisce due tipi di token di accesso. I token opachi sono stringhe casuali che il server delle risorse convalida chiamando l'endpoint di introspezione del server di autorizzazione. I token di accesso JWT sono autonomi: il server delle risorse può convalidarli localmente verificando la firma, riducendo le chiamate all'API di introspezione ma richiedendo la gestione delle chiavi.

I token di aggiornamento sono credenziali di lunga durata utilizzate per ottenere nuovi token di accesso dopo la scadenza del token di accesso. La rotazione dei token di aggiornamento, richiesta in OAuth 2.1 per i client pubblici, emette un nuovo token di aggiornamento a ogni utilizzo e invalida quello precedente. Se viene utilizzato un token di aggiornamento rubato, il client legittimo rileva l'invalidazione, consentendo di individuare il furto del token.

RFC 7662 definisce l'endpoint di introspezione dei token, che consente ai server delle risorse di interrogare il server di autorizzazione sullo stato attuale di un token di accesso opaco (active/inactive), sull'ambito, sul soggetto e sulla scadenza. L'introspezione consente la revoca dei token in tempo reale: una volta revocato un token presso il server di autorizzazione, le chiamate di introspezione restituiscono immediatamente active: false.

RFC 7009 definisce l'endpoint di revoca dei token, che consente ai client di comunicare al server di autorizzazione che un token, di accesso o di aggiornamento, deve essere invalidato. Viene utilizzato durante il logout o quando un client rileva attività sospette. I token di accesso JWT non possono essere revocati completamente senza un elenco di revoca, perché i server delle risorse li convalidano localmente senza contattare il server di autorizzazione.

Gli scope di OAuth 2.0 definiscono le autorizzazioni specifiche richieste dal client. Il server di autorizzazione presenta gli scope richiesti all'utente per l'approvazione. I server delle risorse applicano i requisiti relativi agli scope per ogni endpoint. Si applica il principio del privilegio minimo: i client devono richiedere solo gli scope minimi necessari e i server delle risorse devono rifiutare le richieste con uno scope insufficiente.

Quale flusso OAuth 2.0 è appropriato per uno strumento CLI o un dispositivo IoT che deve autenticare un utente, ma non dispone di browser o tastiera?

Il flusso del codice di autorizzazione è quello corretto per le applicazioni lato server. Il flusso implicito è deprecato: utilizzi invece PKCE. Il flusso ROPC è deprecato perché elimina lo scopo di OAuth. Le credenziali client servono per la comunicazione M2M. L'autorizzazione del dispositivo gestisce i dispositivi con input limitato. I token di accesso possono essere opachi o JWT. I token di aggiornamento devono essere sottoposti a rotazione. L'introspezione (RFC 7662) e la revoca (RFC 7009) completano la gestione dei token.