OAuth 2.0: che cos’è e come funziona?

Cosa diavolo è OAuth 2.0?

OAuth 2.0 è la versione corrente di uno standard aperto creato per consentire alle applicazioni generiche di accedere ai servizi online per tuo conto, ovvero con la tua identità, ma senza fornire a tali applicazioni il tuo nome utente e password per tali servizi.

Cosa significa? Puoi fare un esempio concreto?

Ovviamente. OAuth 2.0, o semplicemente OAuth per brevità, è ciò che, ad esempio, ti permette di postare qualcosa sul tuo blog e poi di averlo annunciato automaticamente su Instagram, Twitter o qualsiasi altro social network, ma senza mai passare al sistema di gestione dei contenuti del tuo blog ( CMS) le password per uno qualsiasi di questi account.

Quindi OAuth 2.0 riguarda l’autenticazione?

No, per niente. OAuth non è un protocollo di autenticazione, ma un sistema standardizzato per autorizzare l’accesso limitato al servizio online. Questa è una distinzione fondamentale! OAuth non ha nulla a che fare con il modo in cui dimostri a Instagram, LinkedIn o chiunque altro di essere veramente te stesso. Fornisce a terze parti quello che viene chiamato “accesso delegato sicuro” solo dopo aver autenticato la tua identità in altro modo.

Bene. Come funziona effettivamente OAuth?

Per svolgere il proprio lavoro, OAuth distingue tra quattro attori o ruoli: proprietario della risorsa, server delle risorse, client e server di autorizzazione. Il proprietario della risorsa è semplicemente l’utente che desidera che del lavoro venga svolto per suo conto, da un client di terze parti, su un server di risorse. Se vuoi che il tuo blog annunci un nuovo post su Instagram, Instagram è il Resource Server, tu sei il Resource Owner del tuo account Instagram e il CMS del tuo blog è il Client. Il server di autorizzazione, il fulcro di OAuth, è il pezzo che, dopo aver verificato l’identità del proprietario della risorsa, fornisce al client quelli che vengono chiamati “token di accesso”.

Token di accesso? Cosa fanno?

I token di accesso sono ciò che effettivamente rende superflua la condivisione delle password. Personalmente, penso che qualcosa come “badge di accesso temporaneo” sarebbe stato un nome molto più chiaro e autoesplicativo, ma alla fine siamo rimasti bloccati con i token, di due tipi diversi. I token di accesso effettivi sono piccoli file che un client deve mostrare a un Resource Server per dimostrare di essere autorizzato, per un periodo di tempo limitato (spesso solo poche ore), ad agire per conto di alcuni utenti. Il formato più utilizzato per i token di accesso OAuth è quello denominato JWT (JSON Web Tokens), che supporta la crittografia e le firme digitali dei dati che trasporta. Oltre ai token di accesso, i server OAuth emettono anche token di aggiornamento, che durano molto più a lungo degli altri ma possono essere revocati in qualsiasi momento. Il loro scopo è consentire ai clienti di richiedere nuovi token di accesso temporanei ogni volta che quelli che stavano utilizzando scadono.

Quindi con un token di accesso un client OAuth può fare tutto ciò che vuole a mio nome?

Non esattamente, ed è questo il bello di OAuth. Ogni token di accesso ha il proprio Scope ben definito , che è un insieme di autorizzazioni a grana fine, ciascuna per un tipo di azione e una sola. Utilizzando diversi Scope, ad esempio, puoi connettere contemporaneamente due Clienti indipendenti al tuo account Twitter, uno autorizzato solo a inviare tweet e l’altro solo a leggere la cronologia di Twitter. Grazie a Scopes, ovvero, OAuth può gestire contemporaneamente tutti i servizi e le applicazioni di cui hai bisogno, ciascuno con autorizzazioni diverse. Molti servizi includono anche una sorta di dashboard OAuth centralizzato, per consentire agli utenti di tenere traccia di quanti Clienti hanno autorizzato, vedere quali autorizzazioni ha ciascuno di essi e aggiornarli o revocarli a piacimento.

Ma in che modo i client OAuth ottengono i token di accesso (o di aggiornamento)?

Per ottenere un token da un server di autorizzazione, è necessario “introdurre” un client OAuth, il che significa che deve avvicinarsi ad esso con alcune prove che qualcuno desidera che riceva quel token.

OAuth 2 definisce tre modi principali per emettere tali “sovvenzioni”. Quello più comunemente utilizzato dai social network e servizi online simili si chiama “Codice di autorizzazione”, mentre le “credenziali cliente” sono (qui sto semplificando!) ottimizzate per scenari machine-to-machine, in cui i programmi software devono ottenere autorizzazioni da altri programmi, non utenti umani. Infine, ci sono le sovvenzioni chiamate “Device Codes”, che sono progettate per dispositivi senza browser o tastiere, come elettrodomestici intelligenti e console di gioco. Senza entrare nei dettagli, tali Codici Dispositivi generano altri codici che il proprietario dei dispositivi può trasmettere manualmente al Server di Autenticazione da un normale browser desktop o mobile per completare la procedura di autorizzazione.

Penso di aver capito come funziona OAuth ora, ma possiamo per favore ripassare l’intero processo?

Certo, vediamo come funzionano tutti i pezzi insieme nel caso in cui il blog chieda l’autorizzazione ad annunciare automaticamente tutti i tuoi nuovi post su Twitter. Per fare in modo che ciò accada, il blog CMS (dopo aver effettuato l’accesso, ovviamente!) ti chiederà se vuoi farlo. Se accetti, il blog presenterà una concessione di autorizzazione che include un codice identificativo univoco, al server di autorizzazione per Twitter. Utilizzando una finestra di dialogo nel tuo browser, quel server ti chiederà di autorizzare esplicitamente una o più azioni (ad es. inviare tweet, rispondere ai tweet, scaricare la tua timeline e così via) di cui ha bisogno per creare l’ambito corrispondente. Se accetti, il server di autenticazione impacchetterà tutto ciò che ha ottenuto come token di accesso e lo invierà al tuo blog CMS. A quel punto, il CMS potrà utilizzare quel token direttamente per contattare il Resource Server, questo è Twitter e fai tutto ciò che hai autorizzato a fare. Hai notato la caratteristica più grande di tutta questa procedura?

Non proprio. Cosa sarebbe quello?

Il fatto che tutto quanto spiegato nel paragrafo precedente può essere ridotto a due flussi indipendenti, uno per la concessione della concessione iniziale, e uno per l’emissione e l’utilizzo degli Access Token veri e propri, che sono gestiti da server diversi, totalmente indipendenti. Questa architettura altamente scalabile, oltre alla granularità delle autorizzazioni fornite da OAuth Scopes, è ciò che rende OAuth 2.0 così utile e di successo.