Abbiamo parlato della condivisione delle password e del fatto che non si dovrebbe mai farlo. Quando un sito Web desidera utilizzare i servizi di un altro sito, come un post di Bitly sullo stream Twitter di un utente, invece di chiederti la condivisione della password, dovrebbe utilizzare un protocollo detto OAuth.
È importante capire in che modo un programma, un sito Web o un'app possono effettuare l'autenticazione da parte tua: hanno le autorizzazioni corrette? Hai concesso loro l'autorizzazione alla verifica della tua identità e all'accesso ai dati per tuo conto? OAuth aiuta a semplificare questo processo: ma anche con l'automazione, occorre sempre essere consapevoli di come una persona o un'azienda utilizza (o archivia) i propri dati.
Leggi la guida essenziale gratuita alla conformità e alle normative sulla protezione dei dati negli Stati Uniti.
Che cos'è OAuth?
OAuth è un protocollo o framework di autorizzazione a standard aperto che consente alle applicazioni di usufruire di un "accesso designato sicuro". Ad esempio, puoi comunicare a Facebook che ESPN.com può accedere al tuo profilo o pubblicare aggiornamenti sulla tua bacheca senza dover dargli la tua password di Facebook. Ciò riduce al minimo il rischio in modo sostanziale: nel caso in cui ESPN subisca una violazione, la password di Facebook rimane al sicuro.
OAuth non condivide i dati delle password, ma utilizza i token di autorizzazione per convalidare un'identità tra consumatori e provider di servizi. Si tratta di un protocollo di autenticazione che consente di approvare un'applicazione che interagisce con un'altra per conto dell'utente, senza comunicare la password.
SAML e OAuth a confronto
SAML (Security Assertion Markup Language) è uno standard di autenticazione federato alternativo, utilizzato da molte aziende per il Single Sign-On (SSO). Lo standard SAML consente alle aziende di monitorare chi ha accesso alle risorse aziendali.
Esistono molte differenze tra SAML e OAuth. SAML utilizza XML per trasmettere i messaggi e OAuth utilizza JSON. OAuth offre un'esperienza più semplice su dispositivi mobili, mentre SAML è rivolto alla sicurezza aziendale. Quest'ultimo punto è un elemento chiave di differenziazione: OAuth utilizza ampiamente le chiamate API, motivo per cui le applicazioni mobili, le moderne applicazioni Web, le console di gioco e i dispositivi Internet of Things (IoT) considerano OAuth un'esperienza migliore per l'utente. SAML, d'altra parte, rilascia un cookie di sessione in un browser, che consente all'utente di accedere a determinate pagine Web, perfetto per giorni lavorativi brevi, ma non quando è necessario accedere al termostato ogni giorno.
Esempi OAuth
L'esempio più semplice di OAuth in azione è un sito Web che chiede: "vuoi accedere al nostro sito Web con l'accesso di un altro sito Web?" In questo caso, l'unica cosa che il primo sito Web, che definiremo consumatore, vuole sapere è che l'utente sia lo stesso su entrambi i siti Web e abbia effettuato correttamente l'accesso al provider di servizi, che è il sito a cui l'utente ha inizialmente effettuato l'accesso, non il consumatore.
Le app di Facebook sono un esempio calzante di caso d'uso di OAuth. Supponiamo che tu stia utilizzando un'app su Facebook, che ti chiede di condividere il tuo profilo e le tue foto. Facebook è, in questo caso, il provider di servizi: ha i tuoi dati di accesso e le tue immagini. L'app è il consumatore e, essendo tu l'utente, vuoi utilizzarla per fare qualcosa con le tue foto. In particolare, hai dato a quest'app l'accesso alle tue immagini, che OAuth sta gestendo in background.
I tuoi dispositivi per la casa intelligente, il tostapane, il termostato, il sistema di sicurezza, ecc., probabilmente utilizzano un qualche tipo di dati di accesso per sincronizzarsi tra loro e consentirti di gestirli da un browser o da un dispositivo client. Questi dispositivi utilizzano ciò che OAuth definisce autorizzazione riservata. In pratica, conservano le informazioni sulla chiave segreta, quindi non è necessario accedere più e più volte.
Spiegazione del funzionamento di OAuth
OAuth riguarda l'autorizzazione, non l'autenticazione. L'autorizzazione richiede il permesso di fare qualcosa. L'autenticazione consiste nel dimostrare che sei la persona giusta perché sei a conoscenza dei dati. OAuth non trasferisce i dati di autenticazione tra consumatori e provider di servizi, ma funge da token di autorizzazione.
L'analogia comune che ho trovato facendo ricerche su OAuth è la chiave del parcheggiatore dell'auto. La chiave del parcheggiatore consente al parcheggiatore di avviare e spostare l'auto ma non gli concede accesso al bagagliaio o al vano portaoggetti.
Un token OAuth è simile alla chiave di servizio del parcheggiatore. Come utente, puoi dire ai consumatori cosa possono utilizzare e cosa non possono utilizzare per ciascun provider di servizi. Puoi dare a ogni consumatore una chiave di servizio diversa. Essi non hanno mai la chiave completa né i dati privati che concedono loro accesso alla chiave completa.
Come funziona OAuth
In una transazione OAuth ci sono 3 attori principali: l'utente, il consumatore e il provider di servizi. Questo trinomio è stato simpaticamente definito il triangolo amoroso di OAuth.
Nel nostro esempio, Joe è l'utente, Bitly è il consumatore e Twitter è il servizio fornito che controlla la risorsa sicura di Joe (il suo stream Twitter). Joe desidera che Bitly possa postare link abbreviati nel suo streaming. Ecco come funziona:
Passaggio 1: l'utente mostra l'intenzione
- Joe (utente): "Bitly, voglio che tu possa pubblicare link direttamente al mio stream su Twitter".
- Bitly (consumatore): "Perfetto". Chiedo l'autorizzazione".
Passaggio 2: il consumatore ottiene l'autorizzazione
- Bitly: "Ho un utente che vuole che pubblichi sul suo stream". Posso avere un token di richiesta?"
- Twitter (provider di servizi): "Certo. Ecco un token e una chiave segreta".
La chiave segreta serve a evitare la falsificazione delle richieste. Il consumatore la utilizza per firmare ciascuna richiesta in modo che il provider di servizi possa verificare che proviene effettivamente dall'applicazione del consumatore.
Passaggio 3: l'utente viene reindirizzato al provider di servizi
- Bitly: "Ok, Joe. Ti sto reindirizzando su Twitter in modo che tu possa approvarlo. Usa questo token".
- Joe: "Ok".
Bitly indirizza Joe su Twitter per l'autorizzazione >
Questa è la parte che genera timori. Se Bitly fosse il loschissimo Evil Co. potrebbe apparire una finestra simile a Twitter ma che in realtà è un tentativo di phishing per sottrarre nome utente e password. Verifica sempre che l'URL verso cui sei diretto sia effettivamente il provider del servizio (in questo caso, Twitter).
Passaggio 4: l'utente concede l'autorizzazione
- Joe: "Twitter, vorrei autorizzare questo token di richiesta che ho ricevuto da Bitly".
- Twitter: "Ok. Giusto per essere sicuri, autorizzi Bitly a fare X, Y e Z con il tuo account Twitter?"
- Joe: "Sì".
- Twitter: "Ok, puoi tornare da Bitly e comunicargli che ha l'autorizzazione per utilizzare il token di richiesta".
Twitter contrassegna il token della richiesta come "pronto", quindi, quando il consumatore richiede l'accesso, sarà accettato (purché sia firmato tramite la chiave segreta condivisa).
Passaggio 5: il consumatore ottiene un token di accesso
- Bitly: "Twitter, posso scambiare questo token di richiesta con un token di accesso?"
- Twitter: "Certo. Ecco un token d'accesso e una chiave segreta".
Passaggio 6: il consumatore accede alla risorsa protetta
- Bitly: "Vorrei postare questo link sullo stream di Joe. Ecco il mio token di accesso."
- Twitter: "Fatto."
Nel nostro scenario, Joe non ha mai dovuto condividere le sue credenziali di Twitter con Bitly. Ha semplicemente delegato l'accesso utilizzando OAuth in modo sicuro. Joe può accedere a Twitter in qualsiasi momento, controllare l'accesso che ha concesso e revocare i token per applicazioni specifiche senza incidere sulle altre. OAuth consente anche livelli di autorizzazione granulari. Puoi concedere a Bitly l'autorizzazione di postare sul tuo account Twitter, ma limitare LinkedIn all'accesso in sola lettura.
OAuth 1.0 e OAuth 2.0 a confronto
OAuth 2.0 è uno strumento completamente rinnovato rispetto a OAuth 1.0 e i due non sono compatibili. Se oggi crei una nuova applicazione, usa OAuth 2.0. Questo blog riguarda solo OAuth 2.0, poiché OAuth 1.0 è obsoleto.
OAuth 2.0 è più rapido e facile da implementare. OAuth 1.0 utilizza complicati requisiti di crittografia, supporta solo tre flussi e non è scalabile.
OAuth 2.0, invece, ha sei flussi per diversi tipi di applicazioni e requisiti e abilita le chiavi segrete firmate su HTTPS. Con la versione 2.0, i token OAuth non devono più essere crittografati sugli endpoint poiché vengono crittografati mentre si trovano in fase di transito.
Altre risorse
Ci auguriamo che questa introduzione sia stata utile per acquisire dimestichezza con OAuth, in modo che la prossima volta che vedrai "Accedi con Twitter" o una analoga verifica basata sull'identità delegata, avrai un'idea più chiara della situazione.
Se vuoi comprendere meglio la meccanica di OAuth, ecco alcuni link utili:
What you should do now
Below are three ways we can help you begin your journey to reducing data risk at your company:
- Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
- Download our free report and learn the risks associated with SaaS data exposure.
- Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
