Data di pubblicazione: 29 luglio 2024
Autori: Gregg Lindemulder, Matt Kosinski
Open authorization (OAuth) è un framework di autorizzazione basato su uno standard aperto che consente alle applicazioni di accedere alle risorse protette di un utente finale, come foto, calendari o post sui social media, senza richiedere l'accesso o la password all'account dell'utente.
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.
Scopri perché KuppingerCole afferma che IBM è leader nella fornitura di soluzioni di autenticazione aziendale mature, scalabili e sicure.
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.
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
Questo è l'utente finale che possiede l'account a cui l'applicazione cerca di accedere, ad esempio un account Facebook o Google. Il proprietario delle risorse fornisce il consenso all'applicazione per accedere a determinate risorse protette in quell'account, come foto o dati personali. In alcuni casi, il proprietario delle risorse potrebbe essere un account aziendale.
Questo è il server che archivia le risorse protette per conto dell'utente. Il server delle risorse accetta e convalida i token OAuth ricevuti dal client, quindi fornisce i dati dell'utente che il proprietario delle risorse ha acconsentito a rilasciare.
Il client è l'applicazione, il sito web, l'API o il dispositivo che richiede l'accesso. Richiede l'autorizzazione dal server di autorizzazione presentando un ID client. Quindi, dopo che il proprietario delle risorse ha fornito il consenso, il client riceve un token di accesso che può utilizzare per accedere alle risorse protette sul server delle risorse.
Questo è il server primario che gestisce il protocollo OAuth. Utilizza due endpoint per concedere l'accesso al server delle risorse.
L'endpoint di autorizzazione richiede al proprietario delle risorse di fornire il consenso per specifiche risorse protette. L' endpoint token riceve quindi la richiesta di token dal client OAuth e genera nuovi token di accesso che garantiscono l'accesso alle risorse.
Gli ambiti sono i parametri di accesso alle risorse protette sul server delle risorse.
Ad esempio, al proprietario delle risorse potrebbe essere chiesto di fornire il consenso per l'accesso a dati come e-mail, file o foto. L'ambito limita l'accesso del client solo a tali elementi.
Di seguito è riportata una panoramica di base del funzionamento di un flusso OAuth:
- Jim (il proprietario delle risorse) vuole consentire a un sito di social media (il client) di accedere ai suoi contatti e-mail (la risorsa).
- Il server di autorizzazione e-mail richiede a Jim di fornire il consenso per l'accesso.
- Dopo aver ricevuto il consenso di Jim, il server di autorizzazione fornisce al sito di social media un token di accesso.
- 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.
- 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.
Proteggi e gestisci clienti, forza lavoro e identità privilegiate sull'hybrid cloud, con l'integrazione dell'AI.
Aggiungi contesto, intelligence e sicurezza all'accesso degli utenti ai tuoi dati e alle tue applicazioni.
Proteggi, controlla e media l'accesso alle API per proteggerle dall'intensificarsi delle minacce.
Ottieni informazioni essenziali per aiutare i tuoi team di sicurezza e IT a gestire meglio i rischi e le potenziali perdite.
Scopri le più recenti tattiche di attacco informatico per proteggere meglio persone, dati e infrastrutture.
In un sistema informatico, l'autenticazione ("auth" in breve) è il processo che verifica che un utente sia chi dichiara di essere.