Condividere in sicurezza informazioni e identità: Oauth 2.0 e OpenID Connect

Pensieri in codice. Idee dal mondo del software, a cura di Valerio Galano. Salve a tutti ragazzi e bentornati su Pensieri in codice. Al giorno d’oggi, in un mondo in cui sempre più aspetti della vita si stanno spostando dalla sfera materiale a quella digitale, la necessità di iscriversi a servizi online, siti web e anche di condividere informazioni fra questi attori sta crescendo ad una velocità sempre maggiore, tanto che la si potrebbe definire esponenziale. I social network aumentano, i servizi di streaming musicale o video on demand aumentano, le piattaforme come G Suite o Office 365 aumentano, i siti di commerce aumentano e molto spesso, vuoi per necessità, vuoi per moda, vuoi per semplice voglia di sperimentare e di intrattenersi, noi siamo lì a rincorrere tanti di questi siti e servizi creando profili e accumulando iscrizioni su iscrizioni. Il risvolto della medaglia però è che, insieme a tutti questi nuovi account creati, arrivano anche altrettante nuove credenziali di accesso. In linea di massima, infatti, ogni nuova iscrizione ad un servizio richiede la creazione di un nuovo set, solitamente composto da un indirizzo email e una password o una username e una password, che dovremo utilizzare per autenticarci e accedere proprio presso questo nuovo servizio. Oltre a ciò c’è poi il problema delle informazioni, che solitamente sono più o meno sempre le stesse e che siamo costretti a inserire e reinserire più volte ad ogni nuova iscrizione e ad ogni utilizzo di un differente e nuovo servizio. Ora, c’è chi risolve questo tipo di problemi con metodi caserecci, come ad esempio usare la stessa password per tutto, e l’abbiamo ormai detto fino alla nausea che è una cosa assolutamente da non fare. C’è chi poi si sobbarca semplicemente l’onere di gestire questa molteplicità in modo manuale, inserendo e reinserendo quello che serve, dove serve e quando serve. E infine c’è chi utilizza delle funzioni specifiche messe proprio a disposizione dalle varie piattaforme per ridurre enormemente il numero di informazioni da inserire e di credenziali da ricordare. Avete presente quei pulsanti colorati che spesso si trovano nelle pagine di autenticazione e che recitano frasi tipo iscriviti tramite facebook o accedi tramite google o collega la tua casella di posta elettronica per scoprire quali dei tuoi amici sono iscritti al nostro servizio e roba del genere? Beh, questi pulsanti sono pensati proprio per far risparmiare tempo nell’attivazione di nuovi servizi e nello scambio di informazioni. Ovviamente questi pulsanti non sono lì perché le piattaforme vogliono essere buone e gentili con gli utenti. Il motivo è semplicemente che a loro fa comodo che l’utente possa iscriversi e inserire le informazioni nel modo più semplice e veloce possibile, perché questo altrimenti costituirebbe una barriera all’ingresso. Ma oggi non sono qui per analizzare il modo in cui le piattaforme usano questi strumenti, quanto piuttosto perché trovo interessanti i meccanismi su cui essi si basano. In questo episodio vedremo dunque come funzionano e su quali protocolli si basano quelle funzioni che permettono agli utenti di condividere informazioni e persino l’autenticazione fra più servizi. In pratica vedremo a grandi linee cosa sono e come funzionano gli standard OAUT e OpenID Connect. Cominciamo dunque parlando della condivisione delle informazioni, che poi ci servirà anche come punto di partenza per capire l’autenticazione. Il concetto di base, come accennavamo nell’introduzione, è che in tanti dei siti web e dei servizi che utilizziamo sono spesso conservate varie delle nostre informazioni e a volte noi possiamo aver bisogno di condividere alcune di queste informazioni tra più servizi o più siti web. L’esempio più classico di questo tipo di informazioni è la nostra rubrica telefonica o nello specifico la rubrica email. In linea generale infatti se abbiamo uno smartphone è probabile che questa rubrica sia archiviata sul cloud che sia di google o di apple a seconda che utilizziamo un android o un iphone. Se quindi volessimo condividere questa nostra lista di indirizzi email e numeri di telefono con qualche altro servizio, magari per scoprire quali dei nostri contatti sono già registrati al servizio o quali possiamo invitare a iscriversi o a quanti possiamo richiedere l’amicizia o iniziare a seguire, avremmo in realtà solo due alternative o eseguire la ricerca a mano cercando uno ad uno tutti i contatti oppure permettere in qualche modo ai due sistemi di dialogare fra loro e scambiarsi automaticamente le informazioni necessarie. Lo standard di sicurezza OAuth ha proprio l’obiettivo di permettere ad un utente di autorizzare un sistema ad accedere alle proprie informazioni contenute in un altro sistema. Si tratta di un tipo di protocolli molto complessi e con varie estensioni e varie sfaccettature quindi per capire come funziona partiamo direttamente da un esempio più o meno comune nel nostro quotidiano e proviamo a descrivere qual è la comunicazione che avviene fra i vari attori in gioco. Immaginiamo quindi di voler utilizzare una funzione di facebook chiamata trova i miei amici. Ora non sono sicuro che questa funzione esista ancora perché non uso facebook da molto tempo però facciamo a capirci. Una funzione di questo genere è implementata sul concetto di confrontare gli indirizzi mail della nostra rubrica, nel nostro esempio poniamo quella di gmail, con quelli utilizzati dagli utenti per registrarsi a facebook. Facendo ciò il social network potrebbe segnalarci le corrispondenze e noi non dovremmo fare altro che richiedere l’amicizia agli utenti ai quali siamo interessati. Badate bene per l’esempio ho usato i nomi dei servizi facebook e google ma giusto per fissare le idee. Meccanismi di questo tipo se ne trovano a centinaia e se implementati correttamente funzionano più o meno tutti allo stesso modo. Diciamo quindi che il concetto di base dell’operazione che stiamo descrivendo è passare a facebook una lista di indirizzi presi dalla nostra casella email. Ora ci sarebbero vari modi per fare questo potremmo ad esempio esportare la rubrica dalla webmail e ricaricarla sul social ma ciò richiederebbe un certo sforzo e probabilmente il tasso di rinuncia sarebbe alto e questo andrebbe a svantaggio sia dei siti che degli utenti. Potremmo dare a facebook le credenziali della nostra casella gmail in modo che possa collegarsi automaticamente e scaricare le informazioni ma voi vi fidereste mai a dare le vostre credenziali di un sito a un altro sito soprattutto uno che custodisce informazioni potenzialmente sensibili? Quello che invece accade nella realtà è che facebook utilizza lo standard OAuth 2.0 per ottenere le informazioni di cui ha bisogno da gmail ma questo solo dopo autorizzazione da parte dell’utente. In questo processo i vari attori in gioco assumono dei nomi particolari. L’utente è definito proprietario dei dati, il server di facebook è definito client e cerca di ottenere questi dati. Il server di gmail nel nostro esempio assume ben due ruoli anche se nella realtà non è sempre così ed in particolare diventa authentication server perché gestisce l’autorizzazione di accesso ai dati e anche il resource server perché conserva materialmente questi dati. Quando clicchiamo sul pulsante trova i miei amici il processo visibile a noi utenti è più o meno questo. Innanzitutto facebook ci chiede di scegliere quale servizio custodisce i nostri dati e in questo esempio noi scegliamo gmail. Veniamo quindi redirezionati verso una pagina di gmail che innanzitutto controlla se abbiamo una sessione attiva e in caso contrario ci chiede username e password. Dopodiché ci mostra un moduletto in cui ci avvisa che facebook sta cercando di accedere a certe particolari informazioni nel nostro caso la rubrica e ci chiede se vogliamo accettare o rifiutare quest’operazione. Se rifiutiamo ovviamente tutto si ferma ma se accettiamo veniamo redirezionati nuovamente su facebook il quale inizia a travasare le nostre informazioni. Ora se si guarda solo alla interfacce il processo non sembra particolarmente interessante ma se si analizzano anche le comunicazioni che avvengono fra i server allora le cose cambiano. Ad esempio nel momento in cui il server di facebook ci redireziona sul server di gmail in background passa anche tutta una serie di informazioni che permettono il funzionamento del protocollo. In particolare fra tutti i dati trasmessi i più interessanti secondo me sono il client id che permette al server di facebook di identificarsi presso il server di gmail in modo da evitare che qualcun altro possa spacciarsi per facebook e poi lo scope cioè l’ambito delle informazioni alle quali il server di facebook vorrebbe accedere. Poi una volta che l’utente ha dato il proprio benestare per l’accesso l’authorization server restituisce al client un codice di autorizzazione il quale lo dovrà riutilizzare assieme alle proprie credenziali di accesso per ricontattare una seconda volta l’authorization server e richiedere un token di accesso. Solo a questo punto il client potrà utilizzare l’access token per effettuare un’ulteriore chiamata e richiedere le informazioni di cui ha bisogno. In tutto questo giro il token di accesso avrà valore solamente per quell’utente e per quelle informazioni autorizzate. In questo modo il facebook del nostro esempio non avrà accesso ad altri dati. Ora mi rendo conto che comprendere questo processo descritto così a parole può essere un po’ complicato e quindi vi lascio in descrizione un articolo che descrive tutto in maniera grafica molto molto chiara. Ma in effetti il processo è proprio complicato di per sé a livello tecnico. Per farlo funzionare va gestita tutta una serie di algoritmi, di politiche, di sicurezza per fare in modo che le chiavi di accesso siano univoche, non falsificabili eccetera e probabilmente descriverle non sarebbe adatto ad un podcast. Ciò che però si può descrivere in modo piuttosto chiaro sono i vantaggi dell’utilizzo di questo sistema. Sicuramente abbiamo già detto quanto sia pratico e semplice da usare ma, e forse questo è un po’ meno evidente a prima vista, questo standard ci garantisce un interessantissimo livello di sicurezza per i nostri dati, per i nostri accessi e per le nostre informazioni. Tanto per dirne una il fatto che durante il processo ci venga mostrato l’ambito delle informazioni alle quali il client vuole accedere già ci aiuta a fare in modo che questo non estragga più informazioni del necessario e in generale ci permette di renderci conto di che cosa stiamo condividendo. Oltre a ciò se in un secondo momento decidiamo che l’accesso a tali informazioni debba essere revocato, l’authorization server solitamente tramite un’interfaccia ci permette di eliminare il token condiviso quindi bloccando il client dall’effettuare qualsiasi accesso futuro e in questo modo l’estrazione di informazioni viene bloccata senza bisogno né di accedere in alcun modo al client né di modificare le proprie credenziali o altre operazioni che potrebbero risultare fastidiose. Insomma si tratta di uno standard di sicurezza molto importante per il mondo di internet così come noi lo conosciamo e se impiegato correttamente fa funzionare tanti siti e tante applicazioni senza che quasi ce ne accorgiamo e soprattutto facendoci risparmiare tempo e fatica. Un meccanismo come quello che abbiamo appena descritto getta le basi per moltissime applicazioni software alcune anche molto complesse con scambi di dati che molto spesso esulano dai contesti a cui siamo normalmente abituati come fruitori del web ma per restare in un ambito il più possibile familiare noi acceneremo ad una di queste applicazioni che probabilmente tutti abbiamo usato almeno una volta nella vita e che prende il nome di OpenID Connect. OpenID Connect è uno strato software che funziona al di sopra dello standard OAUT di cui abbiamo parlato prima. In informatica uno strato software è un certo programma o uno standard o un protocollo che proprio come in una torta appoggia su di uno strato inferiore e sorregge uno strato superiore. Per essere un po’ più pragmatici uno strato software utilizza le funzioni dello strato al di sotto per offrire altre funzioni più complesse allo strato sopra e nel nostro caso specifico OpenID Connect utilizza le caratteristiche di OAUT per fornire ai vari servizi e ai siti web un meccanismo per condividere l’autenticazione degli utenti. In pratica il server che nel protocollo OAUT prendeva il nome di Authorization Server ora diventa l’Identity Provider e invece di fornire l’autorizzazione ad accedere a determinate informazioni ha invece il compito di certificare l’identità dell’utente che sta utilizzando il servizio. In gergo tecnico si dice che il protocollo OpenID Connect permette un meccanismo di Single Sign-On cioè un’unica autenticazione valida per più siti o più servizi. Ora so che può sembrare qualcosa di estremamente complicato se raccontato così ma in pratica stiamo parlando di qualcosa che sicuramente abbiamo incontrato tutti navigando sul web. Tra le varie cose infatti OpenID Connect è lo standard che permette il funzionamento di tutti quei pulsantini accedi con Facebook, accedi con Twitter che si trovano su tantissime pagine di login ai siti. Quando accediamo ad Instagram tramite Facebook stiamo utilizzando OpenID Connect, quando accediamo a un qualsiasi servizio tramite Twitter stiamo utilizzando OpenID Connect ma la cosa interessante è che stiamo utilizzando questo protocollo anche quando non ce ne accorgiamo ad esempio quando ci spostiamo tra i servizi di Google o di Apple. Questi fornitori infatti utilizzano OpenID Connect per evitare ai propri utenti cioè noi di doversi autenticare ogni volta che accediamo ad uno dei loro servizi. A pensarci un attimo infatti quando facciamo login su Gmail poi possiamo anche accedere a Drive o a Meet o a tutti gli altri servizi e questi ci riconoscono automaticamente nonostante siamo di fatto su applicazioni diverse su domini diversi e ciò è possibile proprio perché questi condividono una single sign-on la quale funziona appunto per mezzo di OpenID Connect. Tecnicamente parlando come tutte le cose software fatte bene OpenID Connect implementa potenti funzionalità apportando piccole aggiunte allo strato inferiore nello specifico nel passaggio in cui OAuth genera e trasmette l’access token al client ID OpenID Connect semplicemente, e si fa per dire, aggiunge un ID token. Il flusso delle operazioni quindi per l’utente è quasi identico a quello descritto prima e sta ai due server in comunicazione l’onere di scambiarsi alcune informazioni in più le quali prendono appunto il nome di ID token. Alla fine si tratta di una piccola stringa di dati formattati in formato JSON che contiene alcune informazioni minime riguardanti l’utente ad esempio l’ID, lo username e alcune date di login e discadenza. Sono pochissime informazioni ma ciò non importa perché una volta stabilita l’identità dell’utente il client può recuperare tutto ciò di cui ha bisogno per svolgere le proprie funzioni semplicemente utilizzando l’access token che ha ricevuto insieme all’ID token in fase di login. Oggi abbiamo dunque visto come funzionano dei sistemi di autorizzazione e di autenticazione centralizzati che probabilmente abbiamo tutti usato almeno una volta. Prima di concludere però vorrei aggiungere giusto due parole per una riflessione personale. Di per sé i protocolli che abbiamo descritto funzionano molto bene, sono comodi e sono anche molto sicuri. Se implementati correttamente in generale non c’è da preoccuparsi che qualcuno possa intromettersi nella comunicazione o sottrarre dati in transito o spacciarsi per noi nell’accesso ad un servizio. Tuttavia almeno per come la vedo io bisogna fare attenzione al modo in cui si utilizza questo strumento. Se infatti è vero che utilizzare i pulsanti accedi con facebook o con google o chi che sia per autenticarsi ai vari siti a cui accediamo è comodo, è veloce e non ci costringe a ricordare e inserire un gran numero di password, è anche vero che chiunque riesca ad accedere al nostro account sull’authorization server o peggio ancora sull’identity provider avrà accesso praticamente a tutti i servizi ai quali lo abbiamo collegato. Quello che voglio dire è che se qualcuno riuscisse a scoprire la nostra password di facebook o avesse accesso al nostro computer o al nostro smartphone potrebbe utilizzare i collegamenti che abbiamo creato fra i vari servizi per accedere, leggere, scrivere, modificare, inviare messaggi e chissà che altro. In pratica accentrando tutte le autorizzazioni dietro un unico meccanismo di difesa chiunque dovesse riuscire a superare quella difesa avrebbe praticamente accesso a tutto. Ecco perché, come vi accennavo a inizio episodio, personalmente preferisco non usare questi sistemi. Nessuno dei miei servizi è collegato a google, a facebook, a twitter o ad altri. Ogni accesso ha la sua username e la sua password e tutte le password sono diverse fra loro. Questo sì mi causa un po’ di fatica in più alla quale sopperisco utilizzando un password manager ma al tempo stesso mi dà molta molta più sicurezza. Bene oggi puntata un pochino più lunga del solito quindi senza perdere altro tempo vi ringrazio di aver ascoltato fin qui, vi chiedo di condividere come al solito il podcast e vi saluto ricordandovi che un informatico risolve problemi a volte anche usando il computer.