Cos'è OAuth (open authorization)?

Siti web e applicazioni di terze parti che chiedono agli utenti "Accedere con Google?" o "Consentire l'accesso alle informazioni del tuo account?" sono casi d'uso comuni di OAuth. Il protocollo OAuth consente agli utenti di concedere facilmente a queste applicazioni l'accesso ai dati del proprio account senza condividere le credenziali utente.

Oltre alle applicazioni web, OAuth può anche concedere l'accesso alle risorse ad API, applicazioni lato server, app native del sistema operativo, app mobili e dispositivi come smart TV e appliance. In alcuni casi, non è coinvolto alcun utente umano in quanto OAuth può autorizzare l'accesso alle applicazioni per conto di un'organizzazione o di un account aziendale.

OAuth offre importanti vantaggi nella gestione degli accessi a utenti, sviluppatori e aziende, mantenendo inaccessibili i dati di login e limitando l'accesso ad altre informazioni sensibili. Inoltre, rende più facile per le applicazioni accedere alle informazioni necessarie sull'account senza le vulnerabilità di sicurezza derivanti dalla condivisione delle credenziali utente.

Semplificando l'accesso sicuro, OAuth può aiutare le organizzazioni a risolvere alcune delle loro maggiori sfide di sicurezza. Per esempio, uno studio dell'IBM Institute for Business Value ha rilevato che il 52% dei dirigenti afferma che la complessità è il principale ostacolo alle operazioni di cybersecurity.

Un piccolo team di sviluppatori di software ha rilasciato OAuth 1.0 nel 2007. Questa prima versione del protocollo è stata progettata come alternativa all' autenticazione basata sul web, che richiedeva agli utenti di condividere i propri nomi utente e password con servizi di terze parti. Tuttavia, OAuth 1.0 forniva flussi di autorizzazione solo per i siti web.

Nel 2012, l'Internet Engineering Task Force (IETF) ha rilasciato OAuth 2.0 come RFC 6749 e RFC 6750. Un RFC (Request for Comments) è un documento IETF che descrive i protocolli di comunicazione Internet. RFC 6749 è il framework di base per OAuth 2.0, mentre RFC 6750 definisce il modo in cui il framework utilizza i token di accesso.

Questa versione aggiornata di OAuth ha esteso il protocollo oltre i browser web, includendo funzionalità di autorizzazione per applicazioni, API e dispositivi. OAuth 2.0 ha sostituito OAuth 1.0 ed è ora lo standard del settore.

A differenza di altri framework che si basano su nomi utente e password, OAuth è un protocollo di autorizzazione basato sui token di accesso. I token di accesso sono informazioni che determinano le risorse specifiche a cui un'applicazione può accedere. Il protocollo OAuth definisce come ogni componente in un processo di richiesta di autorizzazione approva, definisce e gestisce i token di accesso.

I token OAuth utilizzano comunemente lo standard JSON Web Token (JWT) per la sua capacità di trasmettere i dati in modo sicuro.

I componenti primari del framework OAuth sono:

• Proprietario delle risorse
• Server delle risorse
• Cliente
• Server di autorizzazione
• Definisci l'ambito

Di seguito è riportata una panoramica di base del funzionamento di un flusso OAuth:

1. Jim (il proprietario delle risorse) vuole consentire a un sito di social media (il client) di accedere ai suoi contatti e-mail (la risorsa).
   
   
2. Il server di autorizzazione e-mail richiede a Jim di fornire il consenso per l'accesso.
   
   
3. Dopo aver ricevuto il consenso di Jim, il server di autorizzazione fornisce al sito di social media un token di accesso.
   
   
4. Il sito di social media presenta il token di accesso al server delle risorse che memorizza le informazioni dell'account di posta elettronica di Jim.
   
   
5. Il server delle risorse riconosce il token di accesso e concede al sito di social media l'accesso ai contatti e-mail di Jim. Poiché il token di accesso include l'ambito del consenso di Jim, il sito di social media non può accedere ad altri dati dall'account di Jim.

La procedura per fornire un token di accesso a un'applicazione è chiamata concessione di autorizzazione o flusso di autorizzazione. Esistono diversi tipi di concessione e flussi OAuth che possono essere utilizzati per diversi tipi di applicazioni, dispositivi o API, come:

• Codice di autorizzazione
• Proof Key for Code Exchange (PKCE)
• Credenziali del client
• Concessione implicita
• Token di aggiornamento

Questo tipo di concessione è in genere utilizzato per applicazioni web e app mobili. In un flusso di codice di autorizzazione, il server di autorizzazione fornisce un codice di autorizzazione monouso al client. Il client può quindi scambiare tale codice di autorizzazione con un token di accesso dall'endpoint del token del server di autorizzazione.

Questo flusso aggiunge ulteriore sicurezza alla concessione del codice di autorizzazione per proteggere le app dagli attacchi di code injection. Questi tipi di attacchi possono indurre le app a eseguire codice dannoso che ne modifica il funzionamento.

PKCE aggiunge un "segreto client" che autentica il client con il server di autorizzazione prima che venga emesso un token di accesso. Poiché solo il client legittimo conosce il segreto, gli autori di attacchi non possono fingere di essere il client e introdurre codice dannoso.

Questo tipo di concessione è progettato per situazioni in cui non è coinvolto alcun utente umano, ad esempio processi automatizzati, interazioni da macchina a macchina e microservizi.

Alle applicazioni viene concesso l'accesso alle risorse di sistema necessarie per svolgere le funzioni, ma non alle risorse dell'utente finale. Ad esempio, la concessione delle credenziali di un client potrebbe consentire a un'app per il meteo di accedere a un'API per recuperare i dati sulle previsioni più recenti.

Questo tipo di concessione offre un flusso più semplice per le applicazioni web JavaScript. A differenza della concessione del codice di autorizzazione, il flusso implicito non richiede un codice di autorizzazione prima dell'emissione di un token di accesso.

Al contrario, dopo che l'utente ha fornito il consenso, il token di accesso è incluso nell' Uniform Resource Identifier (URI) di reindirizzamento che rimanda l'utente all'applicazione che richiede l'accesso. L'app ottiene il token di accesso dall'URI.

Se un token di accesso è scaduto, questo tipo di concessione fornisce all'applicazione un token di aggiornamento che può essere sostituito con un nuovo token di accesso. Senza un token di aggiornamento, l'utente finale dovrebbe fornire nuovamente il consenso affinché l'applicazione riceva un nuovo token di accesso.

La differenza fondamentale è che il single sign-on (SSO) è un protocollo di autenticazione utente, mentre OAuth è un protocollo di autorizzazione.

L'SSO utilizza spesso un provider di identità (IdP) e il Security Assertion Markup Language (SAML), basato su Extensible Markup Language (XML), per autenticare le identità digitali degli utenti tramite nomi utente e password.

OAuth non autentica gli utenti, ma li autorizza ad accedere alle risorse del sistema. Le soluzioni SSO a volte utilizzano OAuth per fornire agli utenti autenticati un facile accesso alle applicazioni e ai servizi nell'intera azienda.

OpenID Connect (OIDC) è un protocollo di autenticazione basato su OAuth 2.0. Lavorando insieme, OpenID Connect può verificare l'identità di un utente, quindi OAuth può autorizzare quell'utente ad accedere a risorse e servizi.