In questo articolo introdurrò lo standard OAuth 2.0 per l'autorizzazione e l'accesso alle risorse protette di servizi web. In particolare presenterò i due "grant" più utilizzati, il Client Credentials grant e l'Authorization Code grant. Infine vedremo come funziona il flusso di aggiornamento dei token (Refresh Token).
Che cos'è OAuth?
OAuth 2 è un protocollo standard aperto che consente alle applicazioni di accedere alle risorse protette di un servizio per conto dell'utente. OAuth 2.0 definisce flussi di autorizzazione per applicazioni native, applicazioni Web e dispositivi mobili.
Molte aziende offrono endpoint OAuth: Google, Facebook, LinkedIn, GitHub sono solo le prime che vengono in mente, ma il loro numero è in costante crescita.
In generale, un processo di autorizzazione può essere descritto come segue:
- L'applicazione invia all'Authorization Server una richiesta di autorizzazione per accedere ad una risorsa protetta
- Il proprietario della risorsa (di solito, l'utente) concede l'accesso
- L'Authorization Server restituisce un Access Token da utilizzare in tutte le successive richieste come una sorta di "cartellino di riconoscimento"
Questa è solo una rappresentazione ad alto livello dell'intero processo, il flusso effettivo differirà in base al tipo di grant utilizzato.
I due tipi di grant più utilizzati sono il Client Credentials grant e l'Authorization Code grant.
Client Credentials grant
Il Client Credentials grant viene utilizzato principalmente in applicazioni "intra-server", come servizi batch o applicazioni a riga di comando. In questo caso l'Authorization Server concede l'accesso all'applicazione piuttosto che all'utente.
Per utilizzare questo flusso, all'applicazione deve essere stato assegnato un client ID e un client secret. Questi parametri sono generati dall'Authorization Server e sono necessari per garantire che il client che si connette sia effettivamente chi dice di essere.
Il processo di autorizzazione funziona più o meno così:
- L'applicazione invia all'Authorization Server una richiesta di autorizzazione assieme ai parametri client id e client secret.
- L'Authorization Server verifica le credenziali fornite
- L'Authorization Server restituisce all'applicazione un Access Token ed eventualmente un Referesh Token.
- L'applicazione utilizza l'Access Token in ogni successiva richiesta al servizio.
Authorization Code grant
L'Authorization Code è di gran lunga il flusso più usato, in quanto viene impiegato da applicazioni che operano effettivamente su risorse di proprietà dell'utente.
Per utilizzare questo flusso, l'applicazione deve essere stata preventivamente registrata presso l'Authorization Server, fornendo almeno un nome e un redirect URI, che verrà utilizzato per informare l'applicazione che l'utente ha autorizzato la richiesta.
Durante la registrazione, il provider assegna all'applicazione un client ID e un client secret, che verranno scambiati durante il processo di autorizzazione.
Per accedere ad una determinata risorsa, l'applicazione deve indicare l'elenco delle "autorizzazioni" richieste, dette scopes. Gli scopes sono definiti dal Resource Server e sono normalmente inclusi nella documentazione del servizio.
Questo flusso può essere riassunto come segue:
- L'utente apre l'applicazione
- L'applicazione apre un'istanza del browser e la fa puntare all'endpoint di autorizzazione presso l'Authorization Server, passando il client ID e l'elenco degli scopes richiesti.
- L'utente si autentica e concede l'accesso alle risorse
- L'Authorization Server reindirizza il client al redirect URI "allegando" un Authorization Token
- L'applicazione emette una richiesta di generazione dell'Access Token, passando l'Authorization Token e il client secret.
- Il server convalida il client secret e l'Authorization Token e restituisce un Access Token ed eventualmente un Refresh Token
- L'applicazione utilizza l'Access Token in ogni successiva richiesta al servizio.
L'estensione PKCE
Il framework OAuth 2 è stato progettato fin dall'inizio per essere estensibile. Dalla sua nascita sono infatti state introdotte diverse evoluzioni, ad esempio per far fronte a potenziali problemi di sicurezza o incrementarne le funzionalità.
Una di queste è PKCE, un'estensione progettata per rendere più sicuro l'Authorization Code grant e limitare le probabilità che l'Authorization Token venga intercettato.
PKCE non introduce alcuna nuova richiesta, ma prevede solamente l'uso di ulteriori parametri nelle richieste standard. In questo modo, i client possono sempre usare l'estensione PKCE anche se il server non la supporta.
Il suo funzionamento è abbastanza semplice:
- l'applicazione genera dapprima un identificativo casuale, il code verifier, al quale viene applicata una funzione di hash per generare il code challenge.
- Il code challenge viene incluso nella richiesta di generazione dell'Authorization Token, assieme agli altri parametri visti in precedenza.
- L'Authorization Server a questo punto genera l'Authorization Token, lo associa al code challenge e lo "restituisce" al client.
- L'applicazione invia la richiesta di generazione di Access Token, includendo l'Authorization Token e il "code verifier".
- L'Authorization Server, prima di generare il token, verifica che il "code verifier" corrisponda al "code challenge" inviato in precedenza, applicando la funzione di hash.
- Nel caso in cui non corrisponda, l'Authorization Server restituisce una condizione di errore, altimenti genera e restituisce l'Access Token.
Con questo sistema, se l'Authorization Token dovesse essere intercettato, non potrà comunque essere utilizzato, perchè la richiesta dell'Access Token dipende dal "code verifier" generato inizialmente.
Scadenza / invalidamento dell'Access Token: il Refresh Token grant
Per limitare il rischio di intercettamento dei token, l'Access Token ha spesso una durata limitata, al termine della quale non potrà più essere utilizzato. Inoltre, l'Access Token potrebbe essere esplicitamente invalidato dal Resource Server.
In questi casi, l'applicazione deve richiedere un nuovo Access Token tramite l'apposito flusso, chiamato Refresh Token. Come suggerisce il nome, questo flusso utilizza il Refresh Token restituito in fase di autorizzazione per generare un nuovo Access Token.
Il processo in questo caso è molto semplice:
- L'applicazione richiede la generazione di un nuovo Access Token includendo nella richiesta il Refresh Token e le credenziali utente utilizzate in prima istanza per la generazione dell'Access Token corrente.
- L'Authorization Server verifica la correttezza del Refresh Token e delle credenziali fornite
- L'Authorization Server genera un nuovo Access Token e possibilmente un nuovo Refresh Token e li include nella risposta
- L'applicazione utilizza il nuovo Access Token in tutte le richieste successive
- Alla scadenza del token, l'applicazione potrà richiederne uno nuovo utilizzando il Refresh Token appena restituito, se presente, oppure il vecchio Refresh Token.
Il vantaggio di questo tipo di grant è che per generare un nuovo Access Token non è necessario l'intervento dell'utente.
L'invio del Refresh Token in fase di generazione dell'Access Token è tuttavia opzionale, la decisione se abilitarlo o meno è lasciata all'Authorization Server. Nel caso in cui il Refresh Token non fosse supportato, l'applicazione non avrà altro modo che avviare un nuovo flusso di autorizzazione per generare un nuovo Access Token, con conseguente intervento dell'utente.
Conclusioni
OAuth 2.0 è un protocollo relativamente semplice che, grazie soprattutto al fatto di essere standard e "open", si presta bene per essere integrato in molti servizi ed API, indipendentemente dalla dimensione dell'azienda.
Nei prossimi articoli applicheremo i concetti introdotti tramite un esempio pratico di autorizzazione presso uno dei provider più conosciuti e della creazione di un client OAuth 2 con Flutter.
Se sei interessato a semplificare l'implementazione di applicazioni OAuth2 per Flutter puoi provare la mia libreria oauth2_client.